I just set up our first live merchant on Balanced Payments and am looking to credit them. In the account creation process, I received the redirect request in my code, I followed that.
I entered in the merchant data and account information, and was successfully redirected back to my site with the account URI and email.
I can successfully retrieve the account via the API, but I do not see it listed in the accounts list page on my balanced dashboard. Is there possibly some lag time before a new live merchant account would show up?
When Balanced creates a merchant for you via the KYC process, you're not passing any authentication information to the API which means Balanced does not have the ability to create objects within your account. This is important to note because:
Balanced will create a Merchant which represents an identity within the Balanced system (this identity is not associated to any particular marketplace), but it doesn't create the actual Account on your marketplace.
The documentation notes that it is the URI of this Merchant which is returned to you, however you will need to then use this identity to create an Account within your marketplace. You are able to do this as you have an API key to authenticate the request.
Here is an example of creating the account using the Balanced Ruby client:
# URL looks like https://yoursite.com/kyc/complete?email_address=merchant#exam
# ple.org&merchant_uri=/v1/merchants/MR3KJZgnQcg8OX8FrTWlRszn
merchant_uri = params[:merchant_uri] # alter to your framework for GET params
email_address = params[:email_address]
merchant = Balanced::Marketplace.my_marketplace.create_merchant(
email_address,
merchant_uri
)
Related
I would like to create a token (asset) on the Ripple XRP ledger.
What transaction type does that?
So far i only found that a wallet called https://www.theworldexchange.net/ supports that activity.
However, i'd like to do it directly on the network. (Ie through a direct transaction)
There is a complete tutorial (published this August) on how to do this here: https://xrpl.org/issue-a-fungible-token.html
The short version is that it's several steps:
You enable the Default Ripple flag on your issuing account by sending an AccountSet transaction with the appropriate flag. This will allow users to swap your token among themselves.
A user sends a TrustSet transaction to your address indicating their willingness to hold your token.
You send the user the token using a Payment transaction.
There are many ways to use tokens on the XRP Ledger, including community credit, but if you are planning on providing a high-quality token for sales to the public, there are a lot of non-technical steps like defining the appropriate policies, establishing a reputation around your token or your business, and (depending on how you use and promote your token) acquiring the appropriate legal licenses or other standing for the jurisdictions you operate in. (In short: Please don't just make a token to cash in on some online craze and then find the SEC knocking at your door shouting that your token fails the Howey Test.)
You can also create a token through the "Token creator" xApp inside the XUMM wallet.
So you would have to download the XUMM wallet app, create and fund an account and open the "xApps" section and find the "Token Creator" xApp which guides you through the process of creating a token on the XRPL.
Issued Currencies are done via OfferCreate transactions.
In order to issue a currency, one just issues an offer to sell a quantity of some new token for some amount of XRP (or other issued currency for that matter)
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I have been trying to figure out after referring to their official documentation (Google Ads API Document) which is not clear enough
Here is what I have tried till now.
I have created an app where users can log in with their Google Ad words account. I need to fetch their Ad performance reports via REST API.
To make an API request to fetch performance reports, we need the Google Ad Words Account ID of the authenticated user. Currently, as I am testing it with my personal account, I can login to my Ad words Console and get the Ad Words Account ID. But, how do I fetch the Ad Words Account ID dynamically for other users who authenticate via my App?
I tried looking for a way in their official documentation. But I couldn't figure out.
Could someone help me with the REST API URL which needs to be called to fetch the authenticated user's Ad words Account ID.
In addition to previous answer, I guess this is what you are looking for:
https://developers.google.com/adwords/api/docs/guides/first-api-call#create_test_accounts
It explains how to setup Google Ad Words API and get your ID.
According to the documentation here Account overview, you need to list the customers to get the ID. For each user that logs in as long as they do not have access to multiple accounts you should get a single customer and their ID.
CustomerService
CustomerService provides information about your accounts. It has a
getCustomers() method that takes no arguments and returns a list of
Customer objects containing fields such as customerId, currencyCode,
and dateTimeZone. CustomerService also has a mutate() method that can
be used to update various attributes of a customer, including the
autoTaggingEnabled and conversionTrackingSetting fields.
If no clientCustomerId is specified in a request, the response will
contain multiple entries if more than one account is directly
accessible by the authenticated account.
As per Paypal Doc's matchCriteria can be NONE only for for certain financial institutions, what does it mean ?
With sending firstName & lastName empty values and matchCriteria as NONE in sandbox environment I'm getting expected response from API call, will this also work in live environment too ? I want to know this before moving my code to production and I didn't found clear information regarding this on doc's.
You will have to create a business application requesting this service to PayPal so they can grant you access. PayPal reviews the different services you are requesting and grants an APP-ID that can be used for API calls. matchCriteria=NONE is an advanced permission.
https://developer.paypal.com/docs/classic/lifecycle/goingLive/
Before first sending signing request I should get a accountId.
So is there any expiration time for this accountID? Can I save it and use it any time with unlimited time if there is no changes in credential or/and other api key and so on?
I can't find information about strategy for accountId in rest api documentation.
Thank you
ref:
https://www.docusign.com/developer-center/recipes/request-a-signature-via-email
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Login.htm
The account ID is part of your developer account. You can find it when you login by clicking on the little down arrow in the top right corner next to your avatar. It will display your name the name of the company then a number. That is the account ID.
The account ID does not expire. The way DocuSign manages access to the API's is through an Integrator key. For information about the Integrator key please refer to the following link. https://www.docusign.com/developer-center/api-overview
So from a broad overview you would want to break up the different business processes by business group and have a different Integrator Key for each unit. That way if someone builds bad code or something strange happens and they turn of one of the Integrator keys it does not affect every group in the company.
There is no expiration of your accountId however note that it will change between environments - i.e. when you move from demo to production. Therefore the best practice is to write your integration such that, for a given user, it makes the login call then uses the accountId returned from that in subsequent API requests. By writing it this way you also make the go live process easier since you wouldn't have to remember to go back and change any hard-coded values in your app.
Note that when you are in production, your organization (or your customers' organizations) may well have more than one account id. And that individuals within the organization may well have access to more than one account.
Example: a company has different rules for electronic signature requests that are sent from the legal department and all the other corporate departments. Depending on the differences in the rules, the best DocuSign configuration may be to establish two different accounts, one for legal and one for everybody else. And some people may have access to both accounts.
Bottom line: when your API integration app logs in, it should enable either the human or your config file to specify the account that should be used (if the user has access to more than one account.) While all users have a "default account," it is not always the case that the default is the one that should be used by your integration.