Payment Initiation and the Developer Experience

Payment initiation is the API use case that changes the checkout experience most visibly. Instead of entering card details, the customer chooses to pay from their bank account, is redirected to their bank to authenticate and approve the payment, and is returned to the merchant with the payment confirmed. The merchant gets the money faster and pays lower fees than for a card transaction, and the customer does not need to share card details with the merchant. Behind the scenes, the payment initiation provider calls the bank's API, the bank runs its usual validation, fraud and sanctions checks, and the payment flows through the normal clearing system. The API is the front door, but the payment itself is processed by the same hub and the same controls as any other payment, which is why banks can offer this service without building a separate payment rail. The developer experience determines whether an API is actually adopted. A good developer portal provides clear documentation, a sandbox environment with test data and test users, sample code in common languages, and a support channel that answers quickly. The sandbox is particularly important, because a developer needs to test the full journey, including authentication, payment initiation, error cases and webhooks, without touching real money. Banks that invest in their sandbox and documentation see faster integrations and fewer support calls, while banks that treat the API as a compliance exercise see slow adoption and frustrated partners. A BA should treat the developer portal as a product, with its own requirements and its own success metrics, such as time to first successful payment in the sandbox. The commercial model for payment APIs is still evolving. Some banks offer basic APIs for free to meet regulatory requirements and charge for premium features, such as higher rate limits, richer data, or guaranteed service levels. Others charge per API call or per payment initiated. For a BA, the commercial requirements, pricing, service levels, and support commitments, are as important as the technical ones, because they shape what the API can promise to its users. The future direction is clear. More payments will be initiated through APIs, more services will be built on top of bank accounts, and the banks that succeed will be the ones whose APIs are reliable, well documented and easy to use. A worked example shows the developer experience. A fintech wants to integrate with the bank API to offer payment initiation to its customers. It starts in the bank developer portal, where it registers its application, receives a client identifier and secret, and reads the API documentation. It then uses the sandbox, a test environment that mimics the production API but with test data, to build and test its integration. The sandbox returns realistic responses, including errors, so the fintech can test its error handling. When the integration works in the sandbox, the fintech applies for production access, the bank reviews its security and compliance, and grants it a production client identifier. The whole process takes days, not months, because the bank has invested in its developer experience. A bank whose developer portal is hard to use, whose sandbox is unrealistic, or whose production onboarding takes months will lose fintech clients to a bank that does it better. A failure scenario tests the sandbox. A fintech builds its integration against the sandbox, but the sandbox does not enforce the same validation as production: it accepts a payment with a creditor account number that is missing a digit. The fintech ships its integration, and in production the same payment is rejected with a 422 error. The fintech's customers complain that payments fail, and the fintech must fix its integration urgently. The lesson is that the sandbox must behave exactly like production, including validation, error codes, and rate limits, or it is worse than useless: it gives the client false confidence. For a business analyst, the requirement is to define the sandbox behaviour, the test data, the error scenarios it must reproduce, and the production onboarding process, and to test that a payment accepted in the sandbox is accepted in production. Last reviewed 7 November 2026. Further reading: Berlin Group NextGenPSD2 API framework; bank API developer documentation. Take a customer buying shoes online for EUR 120. At checkout, the customer chooses pay from my bank, is redirected to the bank's app, authenticates with a fingerprint, sees the payment details, and confirms. The merchant's payment initiation provider calls the bank's API, the bank runs validation, fraud and sanctions checks, and the payment is sent through the normal clearing system. The customer returns to the merchant's site with the payment confirmed, and the merchant ships the shoes. The whole journey takes under a minute, the merchant pays a lower fee than for a card, and the customer never typed card details into a merchant website. That is the value of payment initiation, and it is why merchants adopt it. The redirect is the fragile part of payment initiation. Suppose the customer is redirected to the bank, authenticates, but then closes the app before confirming. The merchant does not know whether the payment was made, the customer does not know whether they will be charged, and the bank holds a payment that was never confirmed. The fix is a clear timeout, a status that the merchant can query, and a message to the customer that says the payment was not made. A BA should specify the timeout, the status transitions, and the customer messages for each abandonment point, because a checkout that leaves the customer unsure whether they paid is a lost customer. Developer experience is a measurable product outcome, and the BA should treat it as one. Time to first successful payment in the sandbox is the key metric: how long does it take a competent developer to go from signing up to making a test payment? If the answer is days, the documentation or the sandbox is broken. The BA should also define the support model: a developer who gets an error at 3 in the afternoon should get an answer the same day, not next week. Banks that invest in their developer portal see faster integrations and fewer support calls, and that is a commercial result, not a technical nicety.