The short answer
To integrate a payment gateway in a way that lasts:
- Keep card data out of your systems by using the provider's hosted payment page, hosted fields or tokenization. This reduces the part of your environment that the payment card security standard applies to.
- Treat payment events as records, not screen messages: store every authorization, capture, refund and chargeback, and process provider notifications (webhooks) reliably.
- Reconcile daily between the gateway, your bank deposits and your accounting or ERP system.
- Put an internal payments layer between your applications and the gateway so you can add methods or change providers without rewriting every system.
Who does what
The terms are often used loosely, so agree on them early:
| Role | What it does |
|---|---|
| Payment gateway | Securely captures payment details and passes transactions to be processed |
| Payment processor | Routes transactions through the card networks or payment systems |
| Acquirer (merchant bank) | Holds the merchant account and settles funds to you |
| Payment service provider or facilitator | Bundles several of these roles, often with simplified onboarding |
Many modern providers combine the gateway, processing and merchant account in one contract. That is simpler, but it makes switching harder unless your integration is designed for it.
Integration patterns
| Pattern | How it works | Effect on your security scope |
|---|---|---|
| Hosted payment page | Customer is redirected to, or shown, the provider's page | Smallest; card data never touches your servers |
| Hosted fields or embedded components | Provider-controlled fields sit inside your page | Small, but your page scripts still need protection |
| Direct API with your own form | Your systems receive card data and send it to the gateway | Largest; you handle card data directly |
| In-person terminals | Card-present payments through certified terminals | Depends on terminal setup and how it links to your POS |
The PCI Data Security Standard applies to entities that store, process or transmit cardholder data, or that could affect the security of the cardholder data environment (PCI SSC). Choosing a hosted pattern does not remove your obligations, but it usually reduces them considerably. Confirm the validation requirements that apply to you with your acquirer.
Designing for reliability
Payments fail in untidy ways: timeouts, duplicate submissions, delayed notifications and partial captures. Build for them:
- Idempotency keys on every request so a retried payment is not charged twice.
- Webhook handling that verifies signatures, stores the event, acknowledges quickly and processes asynchronously, with safe handling of duplicates and out-of-order events.
- A payment state machine in your system (pending, authorized, captured, partially refunded, refunded, disputed) that only moves forward on confirmed events.
- Timeouts and status checks that ask the gateway for the real outcome instead of guessing.
- Clear customer messages that never suggest a payment failed when its outcome is unknown.
Reconciliation and accounting
The checkout is the visible part; reconciliation is where problems surface. Plan to:
- Import settlement reports from the gateway or acquirer each day.
- Match them to orders or invoices and to bank deposits, accounting for fees, refunds, chargebacks and currency.
- Post the results to your ERP or accounting system automatically, with exceptions routed to finance.
- Keep the gateway's transaction identifier on every order, invoice and refund.
US payment methods and modernization
Organizations often need more than cards: PIN debit for in-person payments, ACH debit or credit for recurring billing and some business payments, and wires for larger business-to-business payments. Check which of these each provider supports and how the funds and reports reach you.
The payment system itself is changing. Real-time payment rails now run alongside ACH and wires in the United States, including the RTP network and the Federal Reserve's FedNow service, and the ISO 20022 messaging standard is being adopted across wire and other payment systems. Which of these your bank and your customers can actually use varies, so check current availability with your bank and providers. An internal payments layer makes it easier to adopt new real-time options as they are offered.
If your organization performs payment functions itself, for example holding end-user funds or initiating transfers on behalf of others, check whether money transmitter rules apply. Businesses that transmit money may have to register with FinCEN as a money services business and may need state money transmitter licenses (FinCEN). This is general information, not legal advice.
Future-proofing with a payments layer
A thin internal service that your website, apps, POS and billing system all call, instead of each calling the gateway directly, gives you:
- One place to add payment methods or a second provider for resilience or cost.
- Consistent logging, reconciliation and reporting across channels.
- The option to route transactions by type, currency or amount.
- An easier migration if you change providers, particularly if stored card tokens can be transferred (confirm this in the contract before you sign).
A hypothetical distributor takes card payments on its web store through one gateway, recurring payments through another and invoices by check and bank transfer. It introduces a payments service that both gateways connect to, stores every payment event against the matching ERP invoice and imports daily settlement files for automatic matching. When it later adds a real-time bank payment option, only the payments service changes; the web store and ERP integration stay the same.
Integration checklist
Provider and scope
- Payment methods needed, by channel, listed
- Integration pattern chosen and security scope confirmed with the acquirer
- Token portability and exit terms checked in the contract
Reliability
- Idempotency, webhook verification and duplicate handling designed
- Payment state model defined, including partial refunds and disputes
Finance
- Settlement report format and import schedule agreed
- Matching rules, fees and chargebacks mapped to accounts
- Exception handling owned by finance
Future changes
- Internal payments layer scoped
- Regulatory questions (for example money transmitter rules) reviewed with advisers
Limitations
Provider features, fees and supported methods change often; check current documentation and contracts rather than relying on general comparisons. Connecting payments to an existing ERP, CRM or custom application is integration work at heart. Our business system integration service covers that design and build.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- PCI Data Security Standard (PCI DSS), PCI Security Standards Council
- Financial Crimes Enforcement Network (FinCEN), US Department of the Treasury
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.