User stories and acceptance criteria for payments: Gherkin in practice

A user story in payments follows the same format as any other domain: as a role, I want a capability, so that I achieve a benefit. The role might be a corporate treasurer, a retail customer, an operations analyst, or a compliance officer. The capability might be to send a SEPA Instant payment, to see the status of a payment, or to investigate a returned payment. The benefit might be to pay a supplier on time, to know where the money is, or to resolve an exception quickly. A story without a benefit is a feature, not a story, and a feature without a benefit should not be built. Acceptance criteria in payments must be specific, because the domain is unforgiving. A criterion that says the payment is processed quickly is not testable. A criterion that says the payment is processed within 10 seconds of receipt, 99 percent of the time, and the status is updated within 1 second of each state change, is testable. The criteria must cover the happy path, the exception path, and the failure path, because a payment product that only works on the happy path is not a product. Each criterion must state the input, the expected output, and the measurement. Gherkin is the format that makes acceptance criteria executable. A Gherkin scenario has a Feature, a Scenario, and steps that start with Given, When and Then. For a payment, the Given states the starting condition, such as a customer with a balance of 1,000 euros and a beneficiary with a valid IBAN. The When states the action, such as the customer sends a SEPA credit transfer of 500 euros. The Then states the expected outcome, such as the payment is accepted, the balance is reduced to 500 euros, and a pacs.008 is sent to the clearing system. The scenario is written in plain language, but it is precise enough to automate. A Gherkin scenario for an exception is more valuable than one for the happy path. The Given states a payment that will be rejected, such as a payment to a sanctioned beneficiary. The When states the payment is submitted. The Then states the payment is rejected with reason code AC06, the customer is notified, and the payment is not sent to the clearing system. The scenario proves the product handles the exception correctly, and it proves it in a form the business, the developers and the testers all understand. The exception scenarios must cover every reason code the product can produce. The Definition of Done for a payment story includes the exception handling, the reconciliation, the audit trail, and the documentation. A story is not done when the happy path works. It is done when the happy path works, the exception path works, the reconciliation balances, the audit trail is complete, and the operations team has been trained. The Definition of Done must be written down and applied to every story, because a team that does not apply it will deliver stories that are half finished and will fail in production. Story splitting in payments follows the lifecycle. A large story about sending a cross-border payment is split into stories for initiation, for screening, for the message, for settlement, for status reporting, and for exception handling. Each split story is independently testable, and each one delivers value on its own. A split that produces stories that cannot be tested independently is a bad split, because the team cannot prove any of them work. The analyst must split by lifecycle stage, not by screen or by component. For a business analyst, the user story is judged by whether a tester can test it and a customer can understand it. The acceptance criteria must include a test where the story is read by a customer, a developer and a tester, and all three agree on what it means. Last reviewed 7 November 2026. Further reading: Gojko Adzic, Specification by Example; Matt Wynne and Aslak Hellesoy, The Cucumber Book; the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge; the Gherkin reference documentation.