Pay by Bank
InternalIn reviewThe launch pack for Pay by Bank: customers pay a business directly from their bank account through a guided journey, without entering card details.
How this pack works
The pack has three layers. Each thing lives in one place, and the others link to it.
- Messaging says which words to use: the name, the benefits, what every journey must explain and what not to claim. PMM leads it, and it wins when anything disagrees.
- The Copy library has the finished words: email, push, SMS, WhatsApp, banners, pop-ups and FAQs for each customer scenario.
- A use case pack (Deposits, then Collections and Checkout) says what the experience does: where Pay by Bank sits (Placement), what customers are told before each step (Priming) and how the journey recovers (Pathways). It ends with a checklist.
Every rule, guideline and template has a code, such as DEP-PRI-02. A guideline lists the messaging rules and templates it uses, and they list it back. Client flows will use the same codes to show which guidelines a journey implements.
Mechanisms
Lean supports two Open Finance mechanisms. They are not mutually exclusive: the goal is not to promote one over the other, but to place each where it best matches the customer’s intent.
| Mechanism | The customer approves | Use it |
|---|---|---|
| Single Instant Payment (SIP) | This payment, right now | As the default entry mechanism when the intent is to pay now. |
| Account on File (AoF) | Future payments within clear bounds | As a progressive optimisation, or when the intent is to set up a payment for later. |
AoF works in two modes, depending on who starts the payment: Push, started by the customer, and Pull, started by the merchant or the system. Each mode must be reflected clearly in the UX, the copy and the recovery handling.
Adaptive Payments, which uses SIP and AoF dynamically and removes implementation complexity, has just launched and will be added here. The packs are written per customer state, so their guidance carries over.
Choosing SIP or AoF
- Use SIP when trust is low and the intent is immediate, exploratory or first-time.
- Use AoF when the intent is repeatable, habitual or contractual.
SIP is typically the fastest path to launch and migration. AoF is a second stage of product maturity and needs deeper UX and operational readiness.
Internal and customer terms
SIP, AoF and RE are internal labels. Keep them out of customer-facing copy, and use the terms Messaging sets (Payment method name, One Tap and returning payments).
| Internal | Customer-facing |
|---|---|
| SIP | Pay by Bank |
| AoF | Save your bank account; One Tap for the returning payment |
| Repeat payment | Returning payment |
| Consent | Payment permission; saved bank connection |
| RE (the legacy bank-payment journey) | Only as supporting text: “Previously shown as Instant Bank Transfer”, using the name customers actually saw |
Customer states
Guidelines and templates are written for the state a customer is in, not for the mechanism behind the payment. That way they still hold when Adaptive Payments chooses between a one-time payment and a saved account for the customer.
| State | Who |
|---|---|
| New to Pay by Bank | Has never paid with Pay by Bank and is not moving from the legacy journey. |
| Pays one time | Uses Pay by Bank and approves each payment in their bank, with no saved account. |
| Saved account | Has an active saved bank connection and can use One Tap where eligible. |
| Connection expired | Saved a bank connection that has since expired or been revoked. |
| Legacy journey | Pays with the old bank-payment journey (shown as Instant Bank Transfer) and must set up again. |