If so, are there additional API calls that need to be made from the one's listed in addFundingSource in order to have both under a single Dwolla account?
At the moment I have no way of generating both account types so I can't provide code, but obviously it would help to know if this is even possible first.
As long as a bank account supports ACH transactions, it doesn't matter to Dwolla whether the bank account is intended for for-profit or non-profit use. You should be able to add both kinds of funding sources to a single Dwolla account.
Related
I'm hoping that someone here can assist me with this issue. Stripe support has been underwhelming thus far.
We have a Primary Stripe Account setup in the US
We have customers that will be based out of MX that will connect to the US accounts.
From what we understand here: https://stripe.com/docs/connect/cross-border-payouts there are 2 main criteria that need to occur
We need to make these accounts "Custom"
We need to use the "recipient" option for the account's service agreement.
We also cannot request any other "Capabilities" such as "Card Payments" when setting this up.
Moreover, we have noticed that the moment we use the "Custom" option with Recipient agreement, customers do not have the ability to "Sign In" to their existing Stripe accounts even if they have one. The system always forces them to go through a "new" account setup process. Per Stripe, we are responsible for managing everything including verification of the customer and the customer is NEVER aware of the Stripe account's existence. This has been a hard pill to swallow for some of our larger customers who already have a Stripe account.
Say, we overcome that objection, and say people create new accounts. Now, we're running into a whole new series of problems.
We understand that Stripe requires us to perform separate charges and transfers. Great, we use transfer groups and transfer destination.
However, we also want to use the on_behalf_of parameter so that we attribute the transaction to the connected account for reasons explained here: https://stripe.com/docs/connect/charges-transfers#on-behalf-of
This is where the fun starts. It appears that if you use on_behalf_of, you cannot use "Automatic Payment Methods".
If you specify "card" as a manual payment method type, it will tell you:
You cannot create a charge with the on_behalf_of parameter set to a connected account with transfers but without the card_payments capability enabled.
However, the kicker is that we cannot request card_payments capability for the custom/restricted accounts. So this is a catch22.
So now, we cannot use On Behalf, and essentially, we're acting as the account of record, which is raising alarms in our accounting department.
In addition to that, our customers want to use OXXO, understandably so. This works fine in DEV mode, but when we enable Production, it tells us:
This payment method (oxxo) is not activated for the account specified in on_behalf_of. You can only create testmode oxxo PaymentIntents. You can learn more about this here https://support.stripe.com/questions/i-am-having-trouble-activating-a-payment-method
So, essentially, we are unable to use OXXO w/ or w/o on_behalf.
This makes us think if there are better ways to resolve this issue. We have been trying to get through to Stripe support and their responses have been circular, almost meaningless as they keep pointing us to the documentation and we keep poking holes in their documentation.
Am I missing something here? Looking to see if someone else has had these issues.
Cross-border Payouts as a feature allows US platforms to transfer funds around the world in more countries than Stripe officially in. For example you can accept payments from a customer on your platform and then sends funds to a connected account based in South Africa or South Korea even though Stripe doesn't (at the time of this answer) support those countries for payments.
The overall feature relies on a different type of "agreement" between you and the individual/business you are sending funds to. To do that you have to explicitly set recipient as the service_agreement parameter.
When you go down that path, you can not use on_behalf_of at all. Using on_behalf_of changes a lot of things such as where the payment is being "made from" which Stripe documents here. For that to happen in South Korea or South Africa, Stripe would have to be able to operate and accept payments there. But they can't, and that's why Cross-border Payouts exist in the first place: to let you send funds in countries where Stripe doesn't yet operate. So not using on_behalf_of is entirely expected.
Now, if you don't use on_behalf_of, what you are really doing here is accepting payments yourself, on your US account, through the US. So this limits you to the payment method types that Stripe supports for US accounts. This means you can not use Oxxo for Mexican customers or Konbini for Japanese one. This is a limitation that Stripe likely will lift over time but it's not available today. For example you can accept a lot of European payment methods from the US now which wasn't possible in 2019. In the future, those things will get easier, it's just not the case now.
What I don't fully understand, is why you would go down that path. You clearly say you don't want to be the "merchant of record", you want to do local acquiring, etc. My read is that you simply want to use Destination charges with on_behalf_of. This is supported from US platform to a MX account already. This is something Stripe already supports by default with the "default" services agreement.
While I tried to help with my knowledge, this is really something you have to discuss with Stripe's own support team. They are the only ones that can look at your account details, discuss your business model and understand if they can support you.
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 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 have a subscription service for which free trials are allowed before signing up for the full payed service. I want to ask the customer to provide credit card details before gaining access to the free trial, to prevent abuse of the trial.
I'm using Stripe to handle payments so that I don't have to deal with storage of any sensitive payment information. This free trial scenario would seem to be very common, so I assumed there would be some way to query a card to make sure that it hasn't been used to sign up already. Just some API call that would accept the card number etc. and return a boolean.
I haven't seen anything like in the API docs. I know that fingerprints of cards are accessible after creating a card source, so is it advisable to store them myself and query them? Or have I missed something in the docs?
Just to be clear... I'm not looking to search a card for a particular customer. I know I can iterate over the cards to do that, but I'd have to iterate over the cards of every customer to accomplish what I want, which is not feasible.
Here you probaly want to contact the support team and suggest this as a new feature.
A possibility is the fingerprint you mention, in my opinion this would be the way i would do it too.
One single card should never be associated with one customer in a platform.
No, there is no way to check whether a credit card is used for another customer or not. And there shouldn't be. Because a customer has right to use his/her single credit card to maintain more than accounts.
You can easily integrate trial feature of a Subscription in Stripe which is best way to implement Trial feature using Stripe. If any customer's payment failed after trial expired then you will be notified by Stripe.
And Stripe and any other payment gateway is not advise to store any card info due to security issue.
Say I have a company where I want to make direct deposits to members' bank account. I understand that's it a really bad idea to ask them their information on the site and store it in the database.
But what If i ask our members to email us their bank info for direct deposits? I would then simply take their info and put it in excel sheet instead of storing it in the server(and delete the original email). That would be my reference point to sending the members direct deposits using my bank account. Is that legally allowed? If not, what would be another method to request a member's bank account info to make direct deposits?
Collecting banking account information has significant security implications and doing via email is not kosher. But there are alternatives.
The simplest alternative is using interbank service like Zelle where you can send money to your members' bank accounts using just their email accounts (the one associated with their bank login). We pay our smaller vendors this way and most get paid immediately without any transaction fees. But this may not work for members who use smaller banks outside the network (e.g credit unions) and the service does not have sophisticated tracking or linking to invoices.
If you have international members or need a more scalable/programmatic/self-serve solution, you can consider using a payment gateway provider like paypal/braintree or stripe-connect. Stripe is especially easy to integrate with a website and instead of you collecting and maintaining banking information for your members, stripe does on your behalf. Companies like Lyft use this to pay their drivers. It scales and works in almost all major international locations. Downside is there are per transaction fees which get steep if you want instant payments.