I have 2 managed accounts say A and B and when a credit card is charged, the charge is moved to the managed Account A. Now, I need to move a portion of the amount to Managed Account B at a later point of time. I looked at the link https://stripe.com/docs/connect/payments-fees that provides the following info
Charging through the platform
The second way to perform a charge on behalf of a connected account is to create it on your platform’s Stripe account and use the destination parameter–specifying the connected account ID–in the charge request.
Stripe.apiKey = PLATFORM_SECRET_KEY;
Map<String, Object> chargeParams = new HashMap<String, Object>();
chargeParams.put("amount", 1000);
chargeParams.put("currency", "usd");
chargeParams.put("source", {TOKEN});
chargeParams.put("destination", {CONNECTED_STRIPE_ACCOUNT_ID});
Charge.create(chargeParams);
But, I am unable to set the token paramater for the source
The documentation states that we use the publishable key of the Managed Account B to create a token. But, I am not getting how to generate the token this way. How do I generate this token? or is there another way to make this type of charge?
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)
I am trying to use PayPal Express Checkout with the Braintree SDK and unfortunately the documentation is seriously inadequate in some places. I need to generate a client code on the server (with Java), for which I need to use the following code to generate the gateway object according to the docs:
BraintreeGateway gateway = new BraintreeGateway(useYourAccessToken);
Unfortunately it doesn't explain what access token it is referring to. I seem to be able to generate an access token with 'Generate Sandbox Access Token' under 'My Apps & Credentials' in the PayPal dashboard, and this works. But it has an unusably short expiry date, expiring at the end of today, which obviously makes testing problematic if I have to change the code every day.
There seems to be another constructor for BraintreeGateway, allowing me to pass in an environment specifier (e.g. sandbox), merchant ID, public key and private key. I believe that the public key and private key parameters might be what is visible to me as client ID and secret, in 'SANDBOX API CREDENTIALS', but I'm not sure what merchant ID is.
Any help would be most appreciated.
Idiocy on my part. I wasn't looking closely enough at the expiry date. It's not today, it's 10 years from today! Duh.
Twilio recently stopped their Configuration Profile SID in favor of the new Room Rest API.
Previously I used to create an access token with the configuration profile SID grant and then pass the access token to javascript to connect the participants:
$callerCallId = substr(md5(microtime()), 0, 15);
$callerAccessToken = new Services_Twilio_AccessToken($accountSid, $apiKeySid, $apiKeySecret, 3600, $callerCallId);
$callerConversationGrant = new Services_Twilio_Auth_ConversationsGrant();
$callerConversationGrant->setConfigurationProfileSid($configurationProfileSid);
$callerAccessToken->addGrant($callerConversationGrant);
$callerToken = $callerAccessToken->toJWT();
With the new REST API, what do I do? Twilio's official documentation is not helpful at all.
Twilio developer evangelist here.
If you are on the Video Group Rooms private beta, then you should be able to see the documentation here. You actually don't need to change anything about the way you authorize your users, you will still need to generate the JWT from your server and pass it to the client.
The difference is that rather than creating and joining the room from the client, you will want to use the REST API to create the room first. Then you can use the room name in the client to join that room.
If you have feedback on the API, the documentation or anything about Group Rooms then please get in contact with the Video team on video-product#twilio.com.
I am making a .NET application that will allow potential users to upload invoices they make on my app to their quickbooks account that they have set up and synchronized with their QBD version.
what steps will they/I need to take so that when they use my app, it will upload invoices to their account? Is it:
a) when they set up their account with the Intuit AppCenter, they will pick my app from the app center services (in doing so, it will generate a set of oAuth connection parameters for me to put into my app to push invoices to their account, if so how will I get these)?
b) Will I set up an account via the Intuit Platform Partners, and ask the user to use my account ID and Password by which they will "create new app" under my account for the purposes of generating oAuth connection information for my app to use?
c) Something different from the a) and b)?
Thanks!
The OAuth stuff is specifically designed to allow end-users to push a set of OAuth tokens/credentials from QuickBooks to your app. You then store the OAuth tokens, and use those to communicate with QuickBooks.
This is an accurate description of what happens, yes:
a) when they set up their account with the Intuit AppCenter, they will
pick my app from the app center services (in doing so, it will
generate a set of oAuth connection parameters for me to put into my
app to push invoices to their account, ...
You can read more about that process in the docs:
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0011_from_the_intuit_app_center
The other scenario is that, if you allow it, the user may choose to connect to QuickBooks from within your app. In this case, they'll click the "Connect to QuickBooks" button (see the docs here: https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app) which forwards them to Intuit's site, generates the OAuth tokens, and then sends them back to your site with the OAuth tokens.
In either case, the OAuth tokens will be sent to you so that you can store them and use them to communicate with the QuickBooks APIs.
This:
... and ask
the user to use my account ID and Password by which they will "create
new app" under my account for the purposes of generating oAuth
connection information for my app to use?
Is absolutely not what you want them to do. The whole point of OAuth is that you don't need to share any usernames/passwords of any time with any one.
Here are some additional answers to your other comments:
The part I am trying to figure out is what my customers will need to
do to be able to benefit from my app and its QuickBooks Integration
functionality.
They will need to log in to their Intuit.com account, and follow the prompts to connect their QuickBooks company to your app (i.e. follow the prompts to forward the OAuth credentials to your app).
Sounds like he/she will need to set up some account with ID and
password.
If they don't already have an Intuit.com account, they will be prompted to create one during the OAuth process. In the case of QuickBooks Online, they will ALWAYS already have an Intuit.com account (it's the same thing they use to log in to QuickBooks Online).
Now it seems to me that there are two ways that the customer can set
up accounts with Intuit.
They can set up an account through AppCenter, or within QuickBooks desktop directly (when you install the software, it prompts you) or if you're using any Intuit service already (e.g. QuickBooks Online) then you use your existing QuickBooks Online account.
Developer.Intuit.com accounts are only for developers (e.g. for YOU). Your end-users will not have a developer.intuit.com account. Nor do they need one.
a) what are the differences between the two?
Developer.Intuit.com accounts are only for developers. Your end-user will never see the developer.intuit.com website, nor will they see the option to "Create an App".
b) which should be used if the customer wants to set up syncing their
QBD? c)Which should be used if the customer wants to use my .net App.
d)Which should the customer use if they want both (b) and (c)? e) If
the customer creates an account the 2nd way, won't they get confused
by all the "developer" lingo?
None of those questions are applicable - end-users will never see or be prompted about any of the developer stuff. The only reason you see that is because you're registered as a developer. Normal end-users will not be, and thus won't have any of these options.
f)What if the customer has already synced their QBD with intuit?
Then they can just log in to their existing account to get connected (i.e. to send the OAuth credentials over to your app).
With regards to your questions:
A developer can choose to get his app listed on the appcenter or not depending on mkting requirements.
To understand the difference in the process- you can create a sample and then on developer.intuit.com, go to My Apps-> manage my app-> select your app. Then test connections.
You can use any of the above to use QBD data. Please see the additional info too that I have provided.
Also go through the link which consolibyte has mentioned.
If you are logging in from appcenter app, then since you are already logged in, then only OAUTH will be required.
In logging from within your app, you do not need to provide your user Id and password. The user needs to register for the first time with Intuit.com and then OAUTH process follows for him. These open id/email details can be saved in your db so that user need to enter them a next time.
The customer is never about the details of the developer except for the app which will access their company data.
The sync manager for QBD
OAUTH authorizes your app to connect to their company files.
Any of the above can be used to access QBD data.
The sync manager runs manually or automatically. So, customer can choose to sync/not sync his data.
---------------Addtional info----------
There are two ways to integrate with QuickBooks, the first is with REST APIs and the second is with the downloadable QBXML SDK v12. The REST APIs and that integration model is for applications that are to be sold to customers via our Appcenter. They are generally Saas applications.
The second model is the QBXML sdk which is available for anyone to use, especially for custom integrations.
The reference for the QBXML SDK is here
http://member.developer.intuit.com/qbSDK-current/Common/newOSR/index.html
Please go through:
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits ->QBXML SDK
Lastly through the QBXML SDK you can add a custom field to any entity you want. See the reference above and take a look at DataExt Add Request. and once added Query Request. I believe this will give you what you are looking for.
Keep in mind this is for QuickBooks for Windows not QuickBooks Online.
You can go through FAQ page too-
https://developer.intuit.com/docs/0025_quickbooksapi/0058_faq
I am settled at this point from what Consolibyte has shared and what I have learned also. The whole picture (for me at least) is that both the Developer Account AND the App Center Account is needed. The Developer account provides the consumer key, consumer secret and application token that the .Net app will use to authenticate with Intuit. The App Center Account is needed to allow the user to sync their QuickBooks Desktop data to a location where the app center (and other 3rd party apps) can have access to it (after user authorizes of course), and to give it's user an ID and Password needed to authorize the .net app ( or any app for that matter) to access his/her Intuit data. It is the combination of the Developer Account's tokens and the App center Account's ID and password that allow the generation of an authentication/access token by which the .Net app can instantiate a Dataservices object so it can read/write to the user's instance of QB data in the App Center. Apart from the user creating an account in the App Center and synching their QB Desktop data with it, There should be little or nothing else to do except provide the ID and password, providing the .Net app is coded right. I am not talking about OpenID in this case, but do know that it uses the same ID and password.
...so I'm good. Thx.
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
)