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 tokenisation. 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 authorisation, 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. In Nigeria, check that the provider holds the licence or approval the Central Bank of Nigeria (CBN) requires for the role it plays, and that settlement goes to an account in your company's name.
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. Mobile networks and power interruptions make these cases more common, not rarer, because a customer on a weak connection may submit twice or close the page mid-payment. 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, authorised, 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, since a customer who is told a debit failed may try again while the first one is still pending.
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, VAT on 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.
Nigerian payment methods and change
Organisations often need more than cards: instant bank transfers (NIP), which many customers now use as their first choice, USSD and wallet payments for customers without cards, QR payments in some settings, direct debit mandates for recurring billing and bank transfers for larger business-to-business payments. Check which of these each provider supports, how a transfer is matched to the right order (for example, through a dedicated account number per order where the provider offers it), and how the funds and reports reach you.
Payment options keep changing as banks, switches and fintechs add new methods and the CBN updates its rules. An internal payments layer makes it easier to adopt new options as your banks and providers offer them. If you take payments in foreign currency, or pay dollar-priced suppliers, plan how exchange rates are recorded at the time of each transaction.
If your organisation performs payment functions itself, for example holding customers' funds, initiating transfers on behalf of others or acting as a payment switch or aggregator, check whether CBN licensing or approval applies before you build. Regulated entities should also check CBN guidelines on cybersecurity and on payment service providers (CBN). Payment data also includes personal data, so the Nigeria Data Protection Act 2023 applies to how you collect, store and transfer it (NDPC). 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, which matters when a single provider has an outage.
- 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 cheque 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 an instant bank transfer 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
- Provider licensing or approval status confirmed
- 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 CBN licensing and NDPA obligations) 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
- Central Bank of Nigeria, CBN
- Nigeria Data Protection Commission, NDPC
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.