Information checked: 21 July 2026.
For most small businesses, the safest payment design keeps card data on a hosted or provider-controlled payment page. The website still has responsibilities for account security, scripts, order records, refunds and reconciliation.
In brief: Use a provider-controlled payment flow, verify payment server-side and reconcile every transaction with the business order record.
Choose the payment flow
| Approach | Advantage | Responsibility to examine |
|---|---|---|
| Hosted checkout or payment link | Lower direct exposure to card data | Branding, return flow and order reconciliation |
| Embedded provider component | Smoother on-site experience | Script integrity and correct integration |
| Direct card-data handling | Maximum control | Much larger PCI DSS and security scope |
| Invoice or bank payment | May suit high-value services | Manual matching and customer instructions |
Separate payment from order state
A customer returning to a success page is not reliable proof that payment settled. Use the provider’s verified server notification or API status, store a unique order reference and make processing idempotent so a repeated message does not create duplicate orders.
Plan the full lifecycle
- Authorisation, capture and settlement.
- Failed and abandoned payments.
- Partial and full refunds.
- Disputes and evidence.
- Recurring or saved payment methods.
- Daily reconciliation with orders and bank settlement.
- Access removal when staff or agencies leave.
Protect the payment page
Keep the platform and extensions updated, minimise third-party scripts, inventory authorised scripts and monitor unexpected changes. PCI DSS applies to merchants regardless of size, although the validation route depends on the payment environment.
Acceptance test
Complete successful, declined, interrupted and repeated payments in the provider’s test mode. Test refund and reconciliation, verify no card details enter website logs, and confirm the business can access provider records without the developer.
Example: the success page creates duplicate orders
A payment provider retries a webhook after a temporary timeout. If the website treats every notification as new, one payment can create two orders or emails. Use a stable transaction identifier, verify the provider signature and make processing idempotent. Reconciliation should reveal any paid transaction without one matching business order.
What the business should retain
- Merchant and administrator ownership
- Payment-flow diagram
- Webhook and reconciliation procedure
- Refund and dispute roles
- PCI validation and script inventory
Sources and date checked
Technical and product information was checked against the following primary sources on 21 July 2026. Plans, interfaces and provider terms can change, so recheck them before purchase or migration.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.