# SEPA and US bank debits

SEPA Direct Debit payments settle on the clock, and US bank account payments settle once their microdeposits are verified, with Stripe's test IBANs and codes.

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](https://www.rystic.ai/docs/simulators/stripe/features/balance.md)). 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:

| Input | Result |
|---|---|
| `SM11AA`, or `amounts` 32 and 45 | `processing` with a `pending` charge (`payment_intent.processing`, `charge.pending`); 20 seconds after the charge, the clock settles it as a SEPA payment succeeds |
| `SM33CC`, or `amounts` 10 and 11 | Stripe's 400 `payment_method_microdeposit_verification_attempts_exceeded` |
| `SM44DD`, or `amounts` 40 and 41 | 200, with the PaymentIntent timed out |
| any other code or amounts | Stripe's 400 `payment_method_microdeposit_verification_descriptor_code_mismatch`, with the attempts left |

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.

---

Source: https://www.rystic.ai/docs/simulators/stripe/features/bank-debits · Markdown: https://www.rystic.ai/docs/simulators/stripe/features/bank-debits.md