A shopper chooses to pay a small business directly from a bank account. They approve the transfer using their bank’s app, return to the merchant’s checkout and see a spinning wheel. The payment may have been initiated, but the merchant cannot yet tell whether its order is paid. If the customer presses Pay again, both parties now need an accurate answer to a potentially costly question: how many valid payment instructions exist?
Payment initiation services connect a customer’s instruction to a payment account at another financial institution, with appropriate customer authority and authentication. This differs from account information services that only retrieve authorised data and from acquiring a card transaction. Under the UK’s Payment Services Regulations, an authorised payment initiation service provider (PISP) facilitates a payment order from a user-held online account. Other jurisdictions may structure the service differently. The gold standard is a consent the payer understands and a transfer status both payer and merchant can verify.
For context, Open Banking Account Information Services covers data access, Payment Gateway Services covers checkout integration, and Payment Orchestration covers multiple providers. Here the focus is the actual initiation instruction within the eduKate Gold Standard management approach.
A direct-account payment has four different meanings
| Customer sees | What it may prove | What still needs checking |
|---|---|---|
| Consent recorded | Customer agreed an intended instruction | Bank accepted it |
| Bank authentication | Appropriate bank approval step completed | Transfer executed |
| Initiation accepted | PISP/ASPSP accepted an order | Recipient credited |
| Transfer completed | Bank’s underlying result confirmed | Merchant order correctly matched |
Read the 16 chapters
1. Payment initiation is a request to the bank, not possession of the customer’s money
A PISP can enable a customer to instruct an account-holding provider to make a payment, rather than requiring the customer to key payment details directly into the merchant’s banking arrangements. Under the UK framework, the account-servicing payment service provider (ASPSP) maintains the payment account; the PISP supplies the initiation interface and transmits the relevant request. The two organisations have different legal and operational roles.
The UK FCA’s regulatory explanation distinguishes payment initiation from the aggregation of account information. A trustworthy PISP does not imply it controls the customer’s bank balance, decides all bank security checks, or can guarantee every transfer will settle. Its promise must be specified in the exact service contract and user journey.
2. Ask for explicit authority tied to a particular payment
A customer should see the recipient, amount, currency and meaningful reference before consenting. A vague screen saying “allow access” is not enough to explain a specific debit. Equally, approving a one-off payment should not quietly authorise unrelated withdrawals or indefinite use of account data. Customer-facing terminology should distinguish the merchant’s goods from the payment instruction.
The UK Open Banking Customer Experience Guidelines, current March 2026 version show a consent journey for an identified amount and payee. Apply requirements only where the relevant rules and implementation demand them. The underlying management standard is that the recorded consent matches the instruction actually sent.
3. The recipient and amount must survive the whole handoff
Payment initiation sometimes redirects the customer from a merchant to an initiation service and then to the account-holding bank. Each system may display the beneficiary differently or use its own reference format. A mismatch can cause a payment to an unintended recipient or make a valid transfer difficult to match against the commercial order.
Define the canonical intended amount, currency and beneficiary and test the bank-facing values against them. Capture the bank account or other payment identifier using an approved method and minimise opportunities for unverified substitution. Never assume the payer read every screen: important discrepancies should be presented clearly enough for a reasonable person to notice before authorisation.
4. Authentication and consent are separate parts of the journey
The payer can consent to payment initiation with a provider, then authenticate to the account-holding bank under its applicable security procedure. Authentication establishes the person or account authority in that context; consent establishes which service or payment the customer wishes to authorise. Completing one step does not automatically prove the other occurred correctly.
The FCA’s account information and payment initiation guidance addresses explicit consent and secure customer authentication for the UK’s regulated model. The institution implementing the journey should know which party is responsible at each point, and how failure is communicated without encouraging insecure workarounds or password sharing.
5. Explain the customer journey before leaving the merchant
The customer might be sent to a banking app, complete a challenge and return to the merchant. A sudden change of website or an unexplained request for banking credentials can resemble a scam. The user deserves to understand why the handoff is happening and which established institution they will interact with.
Use clear, consistent provider identity, authenticated links and understandable transition messages. Never instruct customers to ignore browser warnings. Accessibility matters: a successful bank authorisation should not be wasted because the user’s device cannot return to the original application. Offer a legitimate alternate support route without bypassing security requirements.
6. Treat successful initiation and executed payment as different events
The account-holding bank might report that a payment request was received or accepted before the payment is finally executed or credited to the merchant. An integration that displays “paid” on the first acknowledgement can cause goods or course access to be released prematurely. The exact status vocabulary depends on the rail and financial institution.
A gold-standard PISP translates authoritative statuses accurately and retains the bank’s transaction reference and timestamp. Where a particular rail gives near-immediate finality, say what is actually established; where settlement is pending, communicate that limitation. The merchant’s order ledger and the customer’s bank record should reconcile to a single underlying transfer.
7. Avoid duplicate payments after a timeout or lost redirect
A customer can complete banking authentication while the merchant’s callback fails. If the checkout treats any missing return message as proof of failure, it may create a second valid instruction. That is especially harmful for large bills or time-sensitive purchases. An app’s front-end state is not an authoritative account statement.
Maintain an idempotent commercial order reference, traceable initiation object and a procedure for checking uncertain requests. Wait for the bank’s appropriate status before inviting another payment when the result is genuinely unknown. A support agent should be able to reconstruct each attempt without making the customer repeat an already completed transfer.
8. Keep recurring authority separate from one-off authority
Some systems support variable recurring payments under agreed consent parameters. These can permit a series of authorised payments within specified constraints rather than requiring the customer to authenticate each individual instruction in the same way as a new one-off payment. The permitted structure depends on the applicable ecosystem, product and rules.
The Open Banking 2026 guidance on variable recurring payments describes consent parameters and qualifying authentication arrangements. A PISP must not present a broad ongoing mandate as if it were one isolated checkout click. Limits, beneficiary, duration, withdrawal arrangements and actual scope must be visible when relevant.
9. Distinguish an initiation error from an unauthorised transaction
If the customer says a payment was never authorised, the case has a different urgency from a completed authorised payment mistakenly linked to the wrong merchant order. Both merit a traceable review, but the financial rights, responsible institutions and immediate protective steps differ. A PISP should not dismiss an unauthorised-payment concern merely because the integration recorded a button press.
The FCA consumer guidance directs UK users who see unauthorised account payments to contact their bank promptly. A good initiation provider supplies the relevant references and evidence within lawful limits while explaining the proper redress route. The precise statutory rights differ by jurisdiction.
10. Make refunds an explicit separate service decision
A payment initiated from a bank account does not necessarily have the same reversal or chargeback process as a card transaction. A merchant refund can require a new authorised transfer or supported refund mechanism, and the original initiation provider may not control the money after the initial payment completes. Calling everything a “refund” without explaining its route can lead to false expectations.
Tell the customer which party owes the refund, the applicable process, how the receiving account is verified and when funds may arrive. Link any repayment to the original purchase and preserve the reasons. The right outcome is a completed, reconciled correction rather than a service ticket saying the request was sent.
11. Protect customer data according to the payment’s limited purpose
Payment initiation can involve names, account identifiers and information required to execute or track the instruction. It should not become a justification for broad collection of unrelated financial history. A service can be convenient without retaining the customer’s complete banking information or sharing it with every merchant integration partner.
Define the fields actually required, approved recipients, retention and access rules, and deletion or correction handling. The UK rules described by Open Banking Standards place restrictions on information accessed or used by PISPs in their regulated context. Compliance controls should reflect local law and the institution’s actual role rather than marketing claims of absolute anonymity.
12. Build a recovery process for unavailable banks and APIs
The initiating provider can be online while one bank’s interface is unavailable, delayed or rejecting valid requests. A bank integration might return no answer even though a payment is being processed. Simply offering another bank-selection screen can mislead the customer if the earlier instruction still exists.
Monitor account-provider availability, payment status freshness and end-to-end success separately. During an incident, quarantine ambiguous requests, provide a factual message and reconcile completed transfers once connectivity resumes. Technical restoration is not the same as financial restoration; the provider must verify that no customer was charged twice or left with an unresolved order.
13. Test the full payment with a merchant, not only the banking API
A provider may successfully transmit a payment while the merchant’s fulfilment system cannot match the reference. A bank-account transfer intended for a tuition class becomes an unidentified credit that finance staff process manually. The customer sees a debit but receives no course confirmation. Every separate system can claim success while the service fails as a whole.
Use end-to-end tests from amount confirmation and bank authentication to the merchant’s actual receipt and order allocation. Include partial failures, customer abandonment, incorrect beneficiary changes and refunds. Track whether failures are due to account identity, payment processing or a commercial reference mismatch, and repair the correct system.
14. A fictional parent approves tuition fees but the school sees no payment
A parent initiates a bank payment for an examination preparation course. The bank authenticates successfully and posts a debit, but the school’s payment gateway never receives the success callback. The parent tries again and the school ends up with two possible payment references while its enrolment system shows no confirmed order.
A well-managed PISP supplies a stable initiation identifier and bank outcome; the school’s integration verifies the first payment before offering another request. Once the correct receipt is found, the merchant confirms the booking and handles any genuine duplicate through an appropriate repayment process. The fictional case shows why consent, status and commercial fulfilment form one chain.
15. Measure resolved payment journeys rather than requests sent
A PISP may process thousands of initiation requests with excellent API uptime, yet customers experience missing confirmations, failed bank redirects or uncertain refunds. Better indicators are authenticated intended payments, final verifiable outcomes, unknown-state duration, repeated requests, customer error corrections and the proportion of merchant orders reconciled without manual intervention.
Review performance by bank connection and payment method rather than hiding difficult routes in a blended average. Test accessibility, customer understanding and security incident resolution. Good measurement asks whether the payer’s consent produced the intended transfer, not merely whether the PISP received another API response.
16. The gold standard is consent that becomes one trustworthy outcome
Payment initiation can make direct account payments convenient, but it also creates a set of connected responsibilities across merchant, PISP, account provider and payment infrastructure. Every participant should understand the specific scope of its promise. Technology that hides these boundaries has not removed risk; it has only made the eventual complaint harder to resolve.
A gold-standard service presents precise instructions, obtains valid customer authority, preserves authentic security, distinguishes initiation from execution and reconciles the financial result. It never uses ease of payment as an excuse for unclear consent or unverifiable transfers.
Frequently asked questions
Does approving a PISP let it see all my accounts?
Not automatically. Payment initiation and account-information permissions are distinct. Check the specific scope of consent and the provider’s legal rights.
Is a successful banking-app login proof the merchant has been paid?
No. Authentication, acceptance, execution and merchant allocation can be different events. The provider should identify the authoritative status.
Can I cancel a payment after it has been initiated?
Cancellation depends on the rail, timing and contract. A request to cancel is not confirmation that a completed transfer has been reversed.
Who investigates an unauthorised bank payment?
Use the appropriate official bank and provider reporting routes promptly. Exact rights and responsibilities depend on the applicable payment regulations.
Is payment initiation available for every bank account?
No. Availability depends on participating institutions, eligible accounts, payment types, authorised providers and jurisdictions.
A payment initiation service audit
- Verify actual PISP permissions and role under the current local regime.
- Show the exact payee, amount, currency and reference before customer authorisation.
- Keep PISP consent and bank authentication distinct.
- Never equate a browser redirect or initial acceptance with final settlement.
- Deduplicate retries and investigate genuinely unknown transfer outcomes.
- Follow each payment through an accurate merchant reference and usable support route.
Official sources and related Gold Standard chapters
- UK FCA: Consumer Guide to Payment Initiation and Account Information.
- UK FCA: Regulatory Requirements for Payment Initiation Service Providers.
- UK Open Banking Standards: Customer Journey for One-Off Domestic PIS (March 2026).
- UK Open Banking Standards: Variable Recurring Payments (2026).
- eduKate: Open Banking Account Information Services.
- eduKate: Payment Gateway Services.
- eduKate: Payment Orchestration Services.
This is educational financial-service analysis, not a substitute for local payment law or product terms. The UK references apply within their applicable UK framework; initiation permissions, authentication and transfer reversibility vary elsewhere.