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
Related
I want to use Stripe Connect to provide multiparty payments, in my website.
I have a platform. User A (customer) will pay User B (which is the service provider) on the platform and as a platform, I want to get some amount percentage in the middle.
So, I'm following this guide
https://stripe.com/docs/connect/collect-then-transfer-guide
But, when it comes to testing creating those standard connected accounts, I need to fill real information like phones and emails.
However, I found this guide to fullfill my problem:
https://stripe.com/docs/connect/testing#using-oauth
But, I'm not sure how can I use this guide?
How can I create a stripe account for my user B (who will accept payment through my platform) and got that account_id in testing (and later production)?
There are multiple points to clear:
There are Standard, Express and Custom account types. There are also
3 fund flows of Direct Charge, Destination Charge, or Separate
Charges and Transfers. See comparison from Stripe Doc (this is important)
If you decide to use Standard Account, you should go with Direct
Charges
There are 2 ways to onboard a Standard Account. OAuth is a
legacy integration. Account Link is preferable.
But really, Express + Destination Charge would be easier. You should also use Account Link to create express accounts
I am collecting a payment using Stripe, and want to keep a portion, and send the rest onto another account from another organisation.
Stripe have told me that I have to connect an account. I have done this, Stripe gives me a link which the other organisation pastes into their browser, and all works. I can create a transfer linked to a payment intent.
But, when the link is pasted into the other organistions browser, this message is shown.
______ will be able to see your account data (such as all payment and payout history), including any data created by other business you've connected. They'll also be able to create new payments and take other actions for you.
This seems crazy - I just want to pay them some money, not ask them for full access.
Am I missing a trick?
Stripe Connect is a product/tool that allows accounts to work together to provide goods and services to end customers. There are a few different approaches to how this is configured based on your use case as well as whether you would be acting as the Platform (the one in control) or the Connect Account.
You should review the different Connect Account Types and determine what best matches your use case. Some questions to consider are as follows:
Who is interfacing with the end-customer (you or the other account)?
Who is providing the product/service?
Is this other account providing a service to you in exchange for a cut of the revenue?
On what account should the transactions and customers be stored?
It sounds like, based on the warning message, you were creating the other account to be the Platform and you would be Connect Account. In that cases the other account could make API calls on your behalf using your account token. This would be normal if the other account is providing a service to you like funneling customers to you in some way. A good way to quickly review what approach makes the most sense for your use case is to review the Funds Flow diagrams for the different types of Charges
Direct Charges
Destination Charges
Separate Charges and Transfers
I want to include debit/credit card payments powered by papal for my website, I am following the guide as per
https://developer.paypal.com/docs/business/checkout/advanced-card-payments/
but for the code
paypal.HostedFields.isEligible()
I always get the false or undefined as error, may be I skipped something, please help.
I found this answer on the Paypal community.
"In my case, I was using a personal account as a developer account. When I created sandbox credentials from the Business account it started to work. So make sure,
Developer account is linked/created with the business account
Sandbox account is created from that.
Sandbox account should also be a business account and it should be enabled for advanced payments ( Using this link: https://developer.paypal.com/docs/business/checkout/advanced-card-payments/#enable-your-account )"
Here the keypoints:
You need a business account to use advanced payments.
You don't need to have a real business account when working in the sandbox environment: you can create a fake business account in the sandbox and use it.
You need to ask for approval to use the advanced payments. This request must be done separately for sandbox and production accounts.
When loading the Javascript SDK be sure to not pass the disable-funding=card parameter, otherwise isEligible() will return false even if your account has been approved!
I am after the best practice for handling incomplete stripe connected account onboarding.
When onboarding goes smoothly, everything is simple. But there are fiddly edgecases everywhere, which results in a lot of permutations of values for account requirements
These include
current_deadline
currently_due
disabled_reason
errors
eventually_due
past_due
pending_verification
This creates a lot of complexity.
I need a simple way to:
figure out if the connected user needs to be notified of something (i.e. that they need to give more info), and
what to tell them.
My current strategy is to check if errors is empty, and if not, simply display them along with a link to manage the user's stripe account so they can address the errors.
But I'm worried this strategy will miss things (perhaps minor things that could be addressed before they become errors).
TL;DR I suspect most users will onboard without any problem, but for the few who do have issues, I want to ensure the app notifies them that they need to address them. What is the best way to do this? (using the information in requirements or other info)
When handling identity verification manually using the API, a simple way to check whether your connected user might need to be notified to provide more info is to look at the charges_enabled and payouts_enabled properties on the user's account object. If either of these two properties are false then you might need to reach out to the connected user for more information.
In cases where the connected user's charges and payouts are disabled, you would use the disabled_reason property on the requirements hash to learn the reason why charges and/or payouts are disabled. The possible disabled reasons are all documented here, but I'll list them out nonetheless:
action_required.requested_capabilities You need to request
capabilities for the connected account. For details, see Request and
unrequest capabilities.
requirements.past_due Additional verification
information is required to enable payout or charge capabilities on
this account.
requirements.pending_verification Stripe is currently
verifying information on the connected account.
rejected.fraud Account is rejected due to suspected fraud or illegal activity.
rejected.terms_of_service Account is rejected due to suspected terms
of service violations.
rejected.listed Account is rejected because
it's on a third-party prohibited persons or companies list (such as
financial services provider or government).
rejected.other Account is rejected for another reason.
listed Account might be on a prohibited persons or companies list (Stripe will investigate and either reject or reinstate the account appropriately).
under_review Account is under review by Stripe.
other Account isn't rejected but is disabled for another reason while being reviewed.
Using the disabled_reason, you can assess whether the user needs to be notified with a request for more information (i.e., requirements.past_due), whether they need to be notified for another reason (e.g., rejected.listed), or whether you need to make programmatic changes to the user's Stripe account (e.g., action_required.requested_capabilities).
I want to create a platform which will provide a digital service where the customers and connected accounts will be from around the world. Clearly Stripe Connect is the Stripe product to use.
Because many of the connected accounts will be overseas this straight away rules out the use of transfers - unless I explored setting up separate platform accounts in the different overseas countries. (https://stripe.com/docs/connect/capabilities-overview#cross-border-transfers)
So I am left with destination charges where I choose the connected account as the settlement merchant via the on_behalf_of parameter. This means the charge goes against the connected account but I can still make money by charging an application fee.
As the connected account will be invisible to the end customer on the platform it seems inappropriate for the connected account's details to show on the customer's bank / credit card statement. Instead I want the platform's details to show.
Stripe support have assured me it is possible to have only the platform's details. Indeed this part of the API suggests I can control the statement descriptor which shows - https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data-statement_descriptor
But another article - https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data-statement_descriptor - seems to almost contradict this. It explains
Any additional information that’s displayed on a customer’s statement
is also provided by the same account that provides the static
component (business address, phone number).
Can anybody clarify? Many thanks in advance.
Update
This article appears to settle the matter - https://stripe.com/docs/payments/connected-accounts
Guess I will just have to inform users on my website with a connected account that their details will show on the bank statement.