SEPA and US bank debits

Bank debits let you test the payments that do not settle at once: a sepa_debit payment settles on the simulator’s clock, and a us_bank_account payment settles once you verify its microdeposits, each with Stripe’s test values.

SEPA Direct Debit

A PaymentMethod created with type=sepa_debit and an iban, or one a PaymentIntent’s payment_method_data makes, reads the IBAN’s country, last four and bank code, as Stripe’s does; the test IBANs DE89370400440532013000 and DE62370400440532013001 read Stripe’s own fingerprints. A PaymentIntent created with confirm=true and a sepa_debit method, inline or stored, answers processing with a pending charge (a py_ id), sending payment_intent.created, payment_intent.processing and charge.pending.

15 seconds after the charge’s created, the clock settles it, naming no request, in the order Stripe’s do: charge.updated as the charge names its balance transaction, then payment_intent.succeeded and charge.succeeded, and the amount less the card fee moves to pending (Balance and payouts). Stripe settles 12 to 16 seconds after the charge and documents no delay; the fee and balance transactions follow the card’s rule (inferred). The charge of DE62370400440532013001 fails instead: the PaymentIntent returns to requires_payment_method with last_payment_error (payment_intent.payment_failed), the charge reads failed with failure_code incorrect_account_holder_name (charge.failed), then names its balance transaction (charge.updated), and no balance moves. A charge whose PaymentIntent was canceled while processing stays pending. A payment made acting as a connected account settles the same way in that account, moving its balance.

A sepa_debit SetupIntent created with confirm=true succeeds at once, with one succeeded SetupAttempt and a mandate id, as Stripe’s does.

US bank accounts

A us_bank_account PaymentIntent created with confirm=true, a customer and no Financial Connections account answers requires_action with verify_with_microdeposits: the deposits arrive at 07:00 UTC the next day, and hosted_verification_url is on the origin you called, where the simulator serves no page.

POST /v1/payment_intents/{intent}/verify_microdeposits takes descriptor_code or amounts: both answer 400 parameters_exclusive, and neither 400 parameter_missing on descriptor_code, as Stripe’s do. It answers Stripe’s test values, a code in any letter case and the amounts in either order:

A settled US bank payment’s charge carries expected_debit_date and a payment_reference. Its balance transaction is Stripe’s ACH payment: type payment, a 0.8% fee (8 on 10.00) capped at 5.00, created 10 seconds after the verify and available 5 seconds later, its net landing in the balance’s available. Stripe settled 15 to 39 seconds after the verify. SM33CC and SM44DD each return the PaymentIntent to requires_payment_method with last_payment_error and a failed charge, sending payment_intent.payment_failed and charge.failed, and no balance moves. The tenth wrong verify fails the PaymentIntent in its own request, as SM33CC does. A verify on a PaymentIntent not awaiting microdeposits answers 400 payment_intent_unexpected_state, naming its status.

A us_bank_account SetupIntent created with confirm=true and a customer awaits microdeposits the same way, and its verify takes the same inputs and test values. The verifying ones succeed it at once, attaching the PaymentMethod to the customer and sending payment_method.attached and setup_intent.succeeded. SM33CC answers the 400 and SM44DD 200, each leaving the SetupIntent requires_payment_method with last_setup_error and its PaymentMethod unattached, and sending setup_intent.setup_failed. A wrong code answers the mismatch 400, counting the SetupIntent’s own ten attempts; its amounts tests, tenth wrong verify and input refusals follow the PaymentIntent’s (inferred).

Not modeled

Four bank debit paths are not modeled: the confirm route with these methods, a verified payment failing on the clock, a refund of a sepa_debit charge and a SetupIntent’s failing IBAN.