I have some stripe custom connect accounts that need updating.
We create these stripe connected accounts when a user signs up on our platform, but we don't ask for all of the information until later.
Here's the rub: We need a social security number. (We will be doing taxes later) I know that this goes into legal_entity, but the only way to update connected custom accounts is using the secret_key on the back end....but I can't let a SSN touch the back end!....Well, I guess that I could, but I didn't want ANY dangerous information to touch our server, EVER. I definitely wouldn't store it, but I worry about that making me liable.
So if I can't use the secret key in the browser, and I can't let the SSN touch the server....what is the correct way to update a connected account?
Using Stripe.js, you can generate Account Tokens that your server can reference when making API calls, just like you would get a card token when making payments.
There are directions on how to get the token and use it to update legal information in the documentation here:
https://stripe.com/docs/connect/account-tokens#updating
Related
I am following Intuit's oAuth authentication guide in order to log users in through Quickbooks and get access/refresh tokens in order to make API calls. We make API calls in node through the node-quickbooks SDK.
I can successfully log users in through Quickbooks and exchange codes I receive for access and refresh tokens, and I can even make API calls to create invoices successfully.
The problem is, even when I use the tokens of the user I've authenticated to make API calls, the invoice is created in our Quickbooks company instead of theirs.
Is it possible to create invoices in the Quickbooks account of the other user? If not, what's the point of getting access and refresh tokens for them in the first place? For what it's worth, this is all being done in the Quickbooks developer sandbox (but with two separate accounts).
I'm quite confused as to what the methodology is supposed to be here, and any guidance would be very much appreciated -- or even just a reassurance that this is possible.
Thank you!
The QuickBooks instance that's acted on is determined by the Realm ID parameter. The Realm ID is captured when a QuickBooks Online account is selected during the authorization flow.
If we could call your Quickbooks company "Company A" and the one you're trying to create invoices in "Company B", I'd say it sounds like Company A's Realm ID is being logged and passed in subsequent requests instead of Company B's. This could be caused by things by hard-coding Company A's Realm ID and using that for the create invoices requests, selecting the wrong account during the authorization process, or something trickier like a bug in the SDK you're using.
I'd start by getting Company A and B's Company ID, which is what Intuit calls the Realm ID when you access it from the UI. You can do that while logged into a sandbox or production account by pressing Ctrl + Alt + ? in Windows or Control + Option + ? in macOS. Then you can verify the correct Realm ID is being used in the create invoice requests.
If the requests are using the value captured during authentication (as they should be), then you can —in the SDK code— log the Realm ID that's being captured during authorization and verify it's the right one for the company you selected during the OAuth flow.
I was testing Stripe APIs for Connect custom accounts, but for some reason, I keep getting pending verification. I tried to follow docs step by step, and I used testing tokens for account onboarding, created Person object, and uploaded testing files that need to be verified on the dashboard. Without verification, I cannot test payouts. I must have missed extra steps, but I was not able to figure it out. Does anyone know how to make it verified for testing?
I have one more question to make sure that I am not misunderstanding the custom account. Can the platform make a custom account have a direct charge instead of a destination charge? And if possible, is liability for returns and disputes still on platform?
You can check the account's requirements.currently_due hash, it tells you what information are needed to keep the account enabled. You should also use Connect Onboarding to collect the necessary info.
Technically you can create Direct Charge on custom connect accounts. However, it's not recommended. Because:
There's no Dashboard for custom account to address disputes
There's no Dashboard for custom account to set Radar rules
Refunds for Direct Charges on connected account will results in negative balance, which platform needs to cover
I've read the Binance API documentation but it's still not clear to me whether it allows for a 3rd party app to initiate a payment, and then just have the user confirm it.
For example, I want to build an application which would allow the user to send tokens to a previously defined address, but most of my user base won't have MetaMask or a hardware wallet (so it's not that straightforward like with using ethers.js or web3.js), they'll mostly keep their tokens on an exchange.
Also, if this can't be done through Binance, is there another exchnge that would enable this?
You can use the withdraw endpoint.
Docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-user_data
I’m looking at building a solution that allows for users to have an account with my website that is linked somehow to their corresponding stripe customer account. The way I am currently doing this is by using an external database server which holds customer account info such as email, password and stripe customer id. The stripe customer id is used to look up stored credit cards and billing info for the user. The problem I have with this current implementation is that the only reason why I am using an external database for this is to store a password securely (hashed of course) and this seems a little unnecessary.
Another thought I did have was to take advantage of the metadata property of the stripe customer object to store the hashed password. This way all customers live in stripe and that’s it. Is there any issues with doing it this way?
Sounds plausible. Did you try it out?
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.