A successful bank-linking screen can look like the end of a payment flow. It isn’t.
Linking and verifying an account can provide information needed to arrange a payment. The application still needs an authorized payment instruction, a processor to carry it out and a way to follow its outcome.
Plaid Auth illustrates the distinction. Its documentation describes retrieving account information for use with a payment processor; Auth itself is not the movement of money.
For a business adding pay-by-bank, the important choice is how each stage affects the customer experience and the work the system permits. A single green tick cannot responsibly take every shift.
Treat account setup and payment initiation as separate stages
In a fictional membership service, a customer might link an account today and choose to make a payment later. The application should record those as different events.
The first establishes the configured account relationship. The second represents a particular payment, with its own amount, purpose and status.
Verify what the account check actually establishes
A valid account detail is not the same as proof that a particular transfer will succeed. Account ownership, access permission, available funds and return risk are different questions with different verification approaches.
Use the checks appropriate to the processor and business arrangement. Don’t infer a successful payment from a completed account-linking callback.
The screen should be equally precise. “Bank account linked” tells the customer what happened. “Payment complete” makes a further claim that needs further evidence.
This is the kind of problem our custom development team enjoys.
Keep the payment’s identity stable
Give each intended payment a durable internal identifier linked to the customer and the obligation it is meant to satisfy.
When initiating it through the provider, follow the provider’s supported duplicate-prevention and idempotency behavior. A timeout may leave the result uncertain rather than establish that nothing happened.
Stripe’s idempotency guidance explains the general engineering principle, but the chosen payment provider defines the actual contract.3 Reusing a key correctly in one API does not establish the same behavior in another.
| It establishes | It doesn’t yet prove | |
|---|---|---|
| Bank account linked | The customer’s account details are set up for the payment processor | That a particular transfer will succeed |
| Payment initiated | A specific payment instruction, with its own amount, purpose and identifier | That money has moved; after a timeout the result may still be uncertain |
| Pending | The provider is still working on it | A final outcome; ACH payments can still fail or be returned |
| Reconciled | Provider events matched to the original instruction, with the business state updated | Nothing further: this is the state to rely on |
Decide what a pending payment permits
The membership service now faces a business choice: when should the customer receive access?
It might wait for an agreed payment state or allow limited access under a defined policy. The important part is to make that decision explicit and understand how later failures affect it.
Match access rules to the real payment state
Pending, processed and returned can have different meanings across providers and payment rails. Map the provider’s actual statuses into the application’s states rather than relying on labels that sound final.
ACH payments can fail or be returned after initiation. Plaid’s risk guidance discusses why account and payment checks serve different purposes.
For our fictional membership service, immediate access would therefore be a deliberate business decision about pending payments. It should not happen accidentally because the interface treated bank linking as a receipt.
Explain the status to the customer in ordinary language. If an update is still expected, say so and provide the relevant next step. Avoid asking them to initiate another payment just because the first one is taking time to progress.
Worth reading next: Your endpoint is idempotent. The payment still needs protection.
Reconcile the result after the customer leaves
The payment journey continues after the browser closes. Provider events may arrive later, and the application needs to connect them to the original instruction.
Store the provider identifiers, relevant events and resulting business state. Handle repeated notifications without applying the same change twice. When evidence conflicts or an expected update is missing, create a visible investigation path.
An internal payment view should help staff answer what was requested, what the provider reports and what the customer currently has access to. That is more useful than telling them the integration returned a successful HTTP response.
I would rehearse a normal payment, a lost response, a delayed update and a returned payment before depending on the workflow.
The customer can still have a simple experience. The simplicity comes from the application handling these distinctions properly, so the person isn’t left doing payment archaeology with a bank statement and a screenshot.