Payment Processing Integration

This section maps the complete payment lifecycle across checkout, asynchronous provider events, subscriptions, refunds, disputes, reconciliation, invoices and access. The right design depends on the payment methods, merchant model, countries and providers actually used.

Decision summary: Use this hub to choose the relevant guide for checkout, subscriptions, disputes, security, invoices and reconciliation.

The operating model behind the payment flow

For “Payment Processing Integration”, payment providers and methods behave asynchronously. The application must use verified provider events, idempotent processing and reconciliation rather than treating a browser redirect as final proof of payment. Provider features, fees and settlement rules must be checked at the time of procurement.

How to integrate payment processing into a web application

Integrating payment processing means connecting your web application to a payment provider so that money can move between your customers and your business account. The work sits at the intersection of your application's frontend, your backend server and the provider's own systems, and getting the boundaries right between those three layers is where most projects stumble.

There are two broad integration architectures. The first uses a hosted payment page: your application redirects the customer to a page controlled by the payment provider, the customer enters their details there, and the provider sends your server a notification when the payment completes. The second embeds the payment form directly into your application using the provider's JavaScript library, so the card details never touch your server. Both approaches rely on webhooks — asynchronous messages from the provider to your server — to confirm that a payment actually settled, because a customer closing their browser window mid-flow means your application cannot rely solely on what happens in the frontend.

What your specification needs to cover before a developer starts:

• Which payment methods you need to accept (card, direct debit, bank transfer, digital wallets)
• Whether payments are one-off, recurring or a mixture of both
• What your application must do immediately after a successful payment (create an order, grant access, trigger a fulfilment process)
• What should happen on failure, including whether the customer can retry without re-entering all their details
• How your system will store the provider's payment reference ID so that reconciliation and refunds are possible later

A common mistake is treating the frontend response as the source of truth. The customer's browser can lose connection, a tab can close or a network error can prevent your server from receiving the redirect callback. The webhook from the provider is the only reliable confirmation. Your application needs to handle duplicate webhook deliveries gracefully — providers may send the same notification more than once — and your database design should prevent the same payment from being processed twice.

Stripe vs GoCardless vs PayPal for UK businesses

Choosing between payment providers is not about picking a winner from a league table. It is about matching the payment method, integration model and commercial terms to the specific flows your business requires. Three providers frequently considered by UK businesses illustrate how different the options can be.

Stripe is a full-stack payment platform that handles card payments, direct debits (via GoCardless under the hood in some configurations), and a growing range of local payment methods. Its API documentation and developer experience are widely regarded as thorough, and it offers hosted checkout sessions, embedded card forms and a subscription billing engine. Stripe settles to UK bank accounts and supports presentment in multiple currencies. The pricing structure is typically a percentage plus a fixed pence amount per transaction, but the exact figures change and should be checked against the provider's current UK pricing page.

GoCardless specialises in direct debit payments via the Bacs and SEPA schemes. For businesses that collect regular payments — subscriptions, instalments, invoice settlements — direct debit can carry lower per-transaction costs than card payments, and it puts the merchant in control of collection dates rather than waiting for the customer to act. The trade-off is that the customer must authorise a mandate before the first payment, the earliest collection date is typically several working days after authorisation, and customers can dispute payments via their bank. GoCardless also offers a card payment option, but its core strength remains the direct debit rail.

PayPal gives you access to a large existing user base who can pay without entering card details. It is particularly relevant if your customers are consumers who already hold PayPal accounts, or if you sell through marketplaces that expect PayPal as an option. PayPal's API has improved, but developers frequently report that its documentation and error messaging are less consistent than Stripe's. PayPal also operates its own buyer protection programme, which shifts some dispute dynamics away from your business and towards PayPal's own resolution process.

The practical selection criteria come down to a handful of questions. Which payment methods do your customers actually want to use? Does your business model favour card-present-style immediacy or the lower cost of direct debit? Do you need the provider to handle subscription lifecycle events, or will your application manage that logic? What are the settlement timelines, and do they align with your cash-flow requirements? Each provider's current documentation should be checked for the answers, because terms and capabilities change.

Payment security and PCI DSS compliance

PCI DSS — the Payment Card Industry Data Security Standard — is a set of requirements that apply to any organisation that stores, processes or transmits cardholder data. The level of compliance effort depends on how card data flows through your systems, and this is where the integration architecture you chose earlier has direct commercial consequences.

If your application uses a provider's hosted payment page or an embedded form built with the provider's tokenisation libraries, card details are sent directly from the customer's browser to the provider. Your server never sees the full card number. In this model, your business typically qualifies for the simplest self-assessment questionnaire (SAQ A) because you are not handling cardholder data on your own systems. The provider absorbs the bulk of the compliance burden.

If, however, your server receives or stores full card numbers — even temporarily — your compliance scope expands significantly. You would need to complete a more detailed SAQ, implement stricter access controls, maintain logging and monitoring systems, and potentially undergo external assessments. This is almost never justified for a new web application when tokenisation-based options exist.

Tokenisation is the mechanism that makes the reduced-scope model work. When the customer enters their card details into the provider's form, the provider returns a token — a reference string that represents that card without containing the sensitive data. Your application stores and uses only the token for future charges, refunds or subscription billing. The actual card data remains within the provider's environment.

Even with a tokenised integration, your responsibilities do not disappear entirely. You still need to secure the communication between your server and the provider's API using TLS, restrict access to your payment-related API keys, log access to payment functions, and ensure that your application does not log or expose tokens in error messages or debugging output. These are standard application security practices, but they take on particular importance when financial data is involved.

PCI DSS requirements are updated periodically, and the specific SAQ your business needs to complete depends on your payment volume, integration method and merchant agreement. Current guidance should be sought from the PCI Security Standards Council website and from your acquiring bank or payment provider, rather than relying on remembered rules.

How to handle refunds and chargebacks in a web app

Refunds and chargebacks are distinct processes that your application needs to handle separately, even though they both result in money leaving your account.

A refund is initiated by your business. Through the payment provider's API, you request that some or all of a previously collected payment be returned to the customer's card or bank account. Your application should support at least full and partial refunds, and the refund amount should never exceed the original charge. The provider will return a refund reference ID that your system needs to store alongside the original payment record for reconciliation. Refunds are not instant — the time for funds to appear on the customer's statement depends on their bank and the payment method, and your application's customer-facing messaging should set appropriate expectations rather than promising immediate return.

A chargeback, also called a dispute, is initiated by the customer through their bank or card issuer. The bank reverses the transaction and asks you to provide evidence that the charge was legitimate. Chargebacks arrive as webhook notifications from your provider, and your application needs a clear workflow for handling them: recording the dispute, flagging the associated order or subscription, notifying the relevant internal team, and providing a deadline by which evidence must be submitted. Missing a chargeback response deadline typically means an automatic loss.

From a system-design perspective, your admin panel should expose a payment history view for each customer that shows the original charge, any refunds, and any disputes, all linked by the provider's reference IDs. This is the view your finance or operations team will need when reconciling payouts from the provider against your own order records. Without those reference IDs stored correctly at the time of the original payment, reconciliation becomes a manual and error-prone exercise.

One practical mistake to avoid: building refund logic that only works through the admin panel. If your business processes any refunds automatically — for example, prorated refunds on subscription downgrades — that logic needs the same careful handling of reference IDs and amount validation as a manual refund, and it should go through the same code path rather than a separate, less-tested route.

Subscription payment integration

Subscription payments add a lifecycle layer on top of one-off payment processing. Instead of a single charge, your application is managing an ongoing relationship that includes sign-up, recurring billing, plan changes, payment failures and cancellation. The complexity is not in any single step but in the state transitions between them.

Most payment providers offer a subscription or billing product that handles the recurring scheduling, retry logic and webhook events. Using the provider's billing engine rather than building your own scheduler is usually the lower-risk approach, because the provider handles edge cases like month-length variations, failed payment retry cadences and proration calculations that are easy to get wrong.

The subscription states your application needs to account for typically include: trial (if applicable), active, past due (a payment failed but the subscription has not been cancelled yet), cancelled (the customer requested cancellation, but the current paid period has not ended), and expired or ended. Each state should have clear rules about what the customer can access and what messaging they see.

Payment failure handling deserves particular attention. A card expiry, insufficient funds or a bank block will cause a recurring payment to fail. Providers generally retry failed payments on a schedule, but your application needs to decide what happens to the customer's access in the meantime. Cutting off access immediately after a single failure creates poor customer experience; allowing indefinite access during a prolonged non-payment period creates a revenue leak. A common pattern is to allow a grace period — perhaps a few days — during which the customer sees prominent messaging asking them to update their payment details, before access is restricted.

Plan changes — upgrading or downgrading — introduce proration questions. If a customer moves from a monthly to an annual plan mid-cycle, should they receive a credit for the unused portion of the monthly plan? If they downgrade, should the difference be refunded or applied as credit? These are business decisions, not technical ones, but they need to be documented before development begins because the provider's API will offer multiple proration modes and your application needs to call the right one.

Cancellation is another area where business rules must be explicit. Does cancellation take effect immediately, or at the end of the current billing period? Does the customer retain access until then? If you offer an annual plan, is there a refund policy for early cancellation? These rules should be written into your requirements and reflected in the states your application tracks.

Multi-currency and international payments

Multi-currency support becomes relevant when your business charges customers who hold accounts in currencies other than pounds sterling. The decision is not purely technical — it affects pricing strategy, accounting, tax reporting and customer experience — but the integration work has specific requirements that need to be understood upfront.

There are two distinct currency concepts in a payment: the presentment currency, which is what the customer sees on the invoice or checkout page, and the settlement currency, which is the currency in which the provider deposits funds into your bank account. If you present prices in euros but settle in pounds, the provider will convert at its applicable rate, and there will typically be a conversion margin. Whether that margin is acceptable or whether you need to absorb it into your pricing is a commercial decision.

Dynamic currency conversion — showing the customer a price in their own currency based on a live exchange rate — adds complexity. Exchange rates fluctuate, so the amount you actually receive in your settlement currency will differ from the amount at the time the customer viewed the price. If you need predictable revenue in sterling, you may prefer to set fixed prices in each currency and accept that the sterling equivalent will vary, or to price only in sterling and let the customer's bank handle the conversion on their statement.

From an integration standpoint, multi-currency means your application must pass the correct currency code with every payment request, store the currency alongside the payment record, and ensure that any refund is processed in the same currency as the original charge. Your invoice and receipt generation logic must also handle currency formatting correctly — decimal separators, symbol placement and the number of decimal places vary by currency.

VAT and tax implications of cross-border sales are a separate area that requires current specialist advice. The rules on where VAT is due, how it is accounted for and what evidence you need to retain change, and they depend on factors including the customer's location, whether they are a business or consumer, and the nature of what you are selling. Your payment integration can store the customer's country and VAT registration number, but the tax logic itself should be reviewed by a qualified adviser.

Invoicing and receipt generation in web applications

Receipts and invoices serve different purposes, and conflating the two is a common source of confusion during requirements gathering. A receipt is a confirmation of payment — it records that money changed hands, when, and how much. An invoice is a request for payment — it states what is owed, the payment terms and the due date. In many B2C contexts, a receipt is sufficient. In B2B contexts, customers typically require an invoice before they will pay, and they may need a separate receipt or remittance advice afterwards.

There are two approaches to generating these documents. The first is to use the payment provider's built-in invoicing or receipt features. Stripe, for example, can automatically generate and send receipts when a payment succeeds, and it offers an invoicing product that creates sendable invoices with embedded payment links. The advantage is reduced development effort and guaranteed consistency between the payment record and the document. The limitation is that the document format and content are controlled by the provider, which may not match your branding or include all the fields your business requires.

The second approach is to generate documents within your own application. Your server receives the payment confirmation webhook, assembles the document data from your own database (customer details, line items, tax breakdown, payment reference), renders a PDF, and either serves it for download or emails it to the customer. This gives you full control over layout, branding and content, but it introduces a rendering dependency — your application needs a PDF generation library, a template system and a storage location for the generated files.

Whichever approach you choose, certain data points should appear on every document: your business name, address and VAT registration number (if applicable), the customer's name and address, a unique document number, the date, a description of what was charged, the amount, the currency, the VAT amount (if applicable), the VAT rate applied, and the total. For receipts, include the payment method and the provider's transaction reference. For invoices, include payment terms, due date and your bank details.

Document storage and retrieval need to be considered as part of the integration. If your application generates PDFs, where are they stored? If they are stored in your application's file system, that storage needs to be backed up alongside your database. If a customer or your finance team needs to retrieve a historical invoice, your application needs a reliable lookup path from the order or payment record to the corresponding document. Losing access to historical invoices because the storage was not included in the backup strategy is a problem that typically surfaces during a tax audit or a vendor exit.

For UK businesses issuing VAT invoices, the specific requirements for what must appear on the document are set by HMRC and should be verified against current guidance. The rules differ depending on whether the invoice is for a VAT-inclusive amount below a certain threshold, a full VAT invoice, or a simplified invoice for retail transactions. This is an area where the document generation logic should be reviewed against current requirements rather than implemented from memory.

Operational payment checks

• Define the authoritative payment state and the owner of every exception queue.
• Verify current fees, payment-method availability, settlement timing and contract terms directly with each provider before publication.
• Decide which party is merchant of record and who owns refunds, disputes, reconciliation and customer support.
• Use provider-hosted or tokenised payment components where appropriate, but do not assume that outsourcing removes every PCI DSS responsibility.

Primary guidance checked for this edition

Sources for “Payment Processing Integration” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• PCI Security Standards Council: PCI DSS
• Stripe documentation
• GoCardless developer documentation
• PayPal developer documentation