You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(It's worth noting that we're eventually going to merge /v1/charges and
/v1/payments, so we may ask you to switch to another API endpoint nearing
the end of the beta.)
Stripe currently only allows you to debit from a bank account that is attached
to a customer and has been verified via micro-deposit.
To add a bank account to a customer, POST to /v1/customers/{ID}/bank_accounts
with the bank account details, either as a hash or by using a bank account
token created by Stripe.js:
The only thing that can be updated on a bank account is the metadata.
If you would like to change the account/routing information, you must
create a new bank account (and delete the old one if you'd like).
Upon attaching a bank account to a customer, Stripe will send two small deposits
to the bank account (which should take 1-2 business days to appear in the account).
To verify the bank account, have your user confirm the amounts of the two deposits:
ACH payments will clear into your Stripe available balance (or automatically
transferred) after 5 days. During that time, the payment might fail for various
reasons such as an invalid bank account or insufficient funds.
Your customer should expect to see the debit on their bank statement within
1-2 business days.
Webhooks
All payment webhooks contain the payment information as their payload.
payment.created - Right after a successful POST /v1/payments. Note that
the payment will be in the pending state, and can still fail.
payment.paid - This will happen when the payment transitions it's
status from pending to paid. This happens after 5 days.
payment.failed - Before 5 days, if the payment is returned
(insufficient funds, etc) you will receive this hook.
A payment.created webhook will always occur, and only one of payment.paid and
payment.failed will occur.
Testing
To mimic success/failed payment behaviors, you can use the following bank account
information in test mode:
To mimic success/failed verifications, you can use the amounts:
[32, 45] (success)
[any other number combinations] (failure)
Connect Support
Applications can create ACH payments on behalf of their connected
merchants. Just like /v1/charges you may specify an
application_fee to allow your application to take part of the
payment as a fee.
Customer sharing
The process to share a bank account across connected accounts is similar
to sharing cards. The main difference is that bank accounts must be
verified before sharing.
Attach a bank account to a customer in your account (using your secret key)
Verify the bank account using microdeposits
Create a token on the connected account using their access_token
Refunds for ACH payments are handled via ACH transfers back into your customer's
account. As such, they take 1-2 business days to appear on your customer's bank
statement.
API calls
Create a refund
To create a full refund on a payment all you need to specify is the payment to
refund.
If you are using Stripe Connect, you can also refund your application_fee by
specifying refund_application_fee. If the refund is a partial refund, the
amount of the application_fee that will be refunded is proportional to the
amount of the payment and the amount being refunded. For example, if 50% of
the original payment is being refunded, 50% of the application_fee will be
refunded.
However, if the refund fully refunds the payment (either a full refund, or a
partial that refunds the remainder of the payment) then the entire
application_fee will be refunded if refund_application_fee is set to true.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the same way you plan to merge charges and payments, I'd probably like to see a unified view of accounts rather than /customers/{ID}/bank_accounts and cards so I can list all accounts easily.
@ghidinelli do you mean you would like to see all cards/bank accounts that belong to a customer? If so, you can request the customer and get that information. If not, mind explaining a bit more what you would like to do?
Will Stripe ever support ad hoc payments through ACH? Example: making a payment using your checking account in the same manner one would using their credit/debit.
It seems a bit cumbersome (unless this was a decision made for security reasons) that you must first create a customer and verify the account before one can ever make a payment using the account.
@barkerja We have to verify bank accounts before processing the payments. So for now it makes sense to attach them to a customer where you preform the verification response, payments, etc. We are looking at other verification methods, but they will all most likely involve Stripe customer objects as the object you act upon.
@ribzin We are looking into adding instant verification (we are considering a few different providers). If this is a blocker for you, ping me at ray@stripe.com -- love to chat more about a good flow for this.
I can see where the micro deposits would be needed. I'm just worried that the majority of my clients are government agencies (schools, etc.) and will not wish to go through these extra steps. Just some thoughts.
+1 for Customer Sharing support. It would be a big win for us.
It looks like you can add the bank_account reference to a user's Customer object, but the payment API returns a (Status 400) No such bankaccount. I've verified that our app's Customer and the User's customer have a reference to the same account token, so unless I'm screwing up somehow, it seems like a pure access issue.
@hoverlover Canadian banks accounts are not yet supported.
@TheGreenPanda no timeframe yet. Things we are working on: finalizing the API (we want to merge it with charges -- though the current API will continue to be supported for beta users), binding support and dashboard support.
Just a heads up: you can now view ACH payments in your Stripe dashboard. However, at this time it is read-only, but we are adding support for creating and refunding them shortly.
Hi @raycmorgan, will we eventually be able to view attached bank accounts to customers via the admin interface? I know right now we can access them through the API.
Ahoy, @raycmorgan! Monroe sent me here to ask y'ee directly:
Can we have a custom description for the verification deposits and withdrawal (so for example we could direct our clients to login to their account and verify them)?
Is there the ability to change the description each time we make an ACH transfer from their account (to include invoice numbers, etc.)?
Currently verification deposits are being recorded in our customer's bank statements as "postage pirate | TRANSFER VERIFICATION X", and transfers are being recorded as "postage pirate | TRANSFER X". We'd love to get our name properly capitalized and something that describes the transaction a little more at least, and ideally we'd love to turn this into a branding & information opportunity with custom text.
Thanks so much for all you're doing! Being able to use ACH through Stripe is awesome.
The micro-transaction verification is something we'll need to build into the software we're creating (not that it's hard). We're mainly concerned about the barrier to entry for our end users. They'll need to wait for micro-transactions to clear, check their bank ledger online, go back to our software, and enter those transactions, etc. If it doesn't work, our support team will then pick up the burden of figuring out where the customer made an error. Most of all, we anticipate losing customers somewhere in a setup process that spans a few days.
PS: Stripe first appeared on my radar at a conference a couple years ago where @collision spoke. Such a great talk!
We're mainly concerned about the barrier to entry for our end users.
We have the same concerns, especially since a majority of our transactions would be made from "public" users, which adds a whole other dynamic. We would need to design a way to "track" those public users so that they could return to confirm the micro-deposits.
As with many here, logging in to the bank for verification would be really beneficial.
Another strategy that Square employed is using debit card for fixed fee debit transfers. For many, debit card numbers are more reachable than bank account + routing.
In the same way you plan to merge charges and payments, I'd probably like to see a unified view of accounts rather than /customers/{ID}/bank_accounts and cards so I can list all accounts easily.