Digital payment processing
Digital payment processing covers everything that happens between pressing the pay button and the funds being credited to the merchant's account. This area describes the payment lifecycle, the parties involved and the technical solutions that make the process reliable.
Why payment processing is more complex than it looks
To the user, a payment is a single event. Technically, it is a sequence of state transitions that typically involves a payment gateway, a payment processor, the payer's bank or card issuer, the payee's bank or acquirer, and one or more settlement systems. Each party maintains its own view of the payment's status, and the reliability of the whole depends on how these views are kept consistent.
In card payments, authorisation and the actual movement of funds (clearing and settlement) are separate steps that can be days apart. In account-to-account (A2A) payments, the payer approves the transfer directly in their own bank, and via an instant payment system the funds can arrive within seconds. In modern A2A payments, the payer authenticates directly with their own bank's authentication method, which can make the payment journey short and smooth without entering separate card details. Different time spans mean different risks: in card payments the risk often relates to subsequent chargebacks, whereas in bank transfers it relates to the irrevocability of the payment and to making sure the payee is the right one.
When a merchant offers several payment methods, the challenge becomes a unified status model, refund management and accounting reconciliation. A well-designed payment architecture separates method-specific integrations from a shared state machine, records every state transition in an immutable log and reconciles transactions daily against the bank's or provider's reporting.
Brevixoo does not process or relay payments. The purpose of this page is to describe general architectural principles that can be used alongside providers' own documentation.
The payment lifecycle in six steps
The steps are described independently of the payment method. The content of each step differs between card payments and account-to-account payments, but the structure is the same.
Creating the payment request
The merchant's system creates a payment request containing the amount, currency, reference and a unique idempotency key. The request is stored in the "created" state.
Choosing the payment method
The payer chooses a payment method. For card payments the card details are tokenised; for bank transfers the payer is redirected to their bank's service.
Authentication and approval
The payer is strongly authenticated in accordance with PSD2. The approval is dynamically linked to the amount and the payee.
Authorisation or initiation
The card issuer authorises the card payment or the bank executes the payment order. The response is an approved or rejected status.
Settlement and delivery
The funds move through the settlement system. With instant payments this happens within seconds; with card payments and standard transfers, later.
Reconciliation and reporting
Transactions are reconciled against the provider's reports and the bank statement, exceptions are handled and the accounts are updated.
Where payment processing architecture makes the difference
The same principles recur regardless of the sector. The differences arise from volumes, payment methods and risk profile.
E-commerce
Parallel support for several payment methods, a unified status model and automated refund handling.
Subscription services
Recurring charges, management of payment mandates and retry logic for failed charges.
Platform economy
Distributing funds to multiple payees and keeping intermediated funds segregated.
Invoicing and B2B
Using ISO 20022 references for automatic matching and accounts payable.
Public services
Accessible payment journeys, strong authentication and a long-term audit trail.
Payment refunds
A controlled refund process in which the refund is matched to the original payment and account.
Typical risks and controls
The table summarises the most common payment processing risks. The list is not exhaustive, and a risk assessment should always be carried out case by case.
| Risk | Description | Control |
|---|---|---|
| Double charging | A retry after a network outage creates a second payment. | Idempotency keys and a server-side status check before any new request. |
| Status mismatch | The merchant's and the provider's view of the payment status differ. | Signed webhooks, status queries and daily reconciliation. |
| Card data leakage | Sensitive data ends up in the merchant's systems. | Tokenisation, hosted payment fields and compliance with PCI DSS requirements. |
| Wrong payee | A bank transfer is directed to the wrong account through fraud or error. | Verification of payee (VoP) and risk-based transaction monitoring. |
| Refund errors | A refund is matched to the wrong payment or exceeds the original amount. | Binding the refund to the original transaction identifier and amount limits. |
- PCI DSS v4.0
- The security standard for handling card data. The future-dated requirements of version 4.0 became mandatory on 31 March 2025.
- PSD2 / RTS 2018/389
- Strong customer authentication and dynamic linking in electronic payments.
- ISO 20022
- Structured payment messages that enable rich reference data and automatic matching.
- Regulation (EU) 2024/886
- Availability of instant payments, verification of payee and price parity.
Questions: digital payment processing
What is the difference between a payment gateway and a payment processor?
A payment gateway is a technical interface that receives the payment request and passes it on. The payment processor handles the actual communication with card networks or banks. In practice, many providers combine both roles in the same product.
Why is idempotency so important?
Network connections drop, and the client does not always know whether a request got through. Thanks to an idempotency key, the same request can be sent again safely: the server recognises the key and returns the original response instead of creating a new payment.
Can an account-to-account payment be reversed?
An instant transfer is in principle irrevocable once it has been executed. An erroneous payment is usually returned through a separate refund payment or a recall request. This is why verifying the payee before approval is a key control.
How often should reconciliation be carried out?
Common practice is at least daily automated reconciliation, with exceptions handled within a defined time. At high volumes, reconciliation is often performed almost in real time at transaction level.
Related topics
Other technology areas and knowledge base guides that go deeper into this topic.
Secure authentication protocols
Strong customer authentication (SCA), bank IDs, OAuth 2.0 / FAPI and dynamic linking in the PSD2 environment.
Read more → Technology areaTransaction infrastructure
SEPA schemes, TIPS and RT1, ISO 20022 messages, idempotency, availability and operational resilience.
Read more → GuideTrustly, Brite, Zimpler and Trumo: a technology comparison
Four account-to-account payment solutions from a payment technology perspective: architecture, authentication flow, payment rails, refunds and integration design.
Read the guide →Is something important missing?
Suggest a topic or send a correction. We update our content as regulation and standards change.