Payment Gateway Integration Cost in Nigeria (2026): Paystack, Flutterwave and Real Checkout Work

Paystack says zero integration fee. Flutterwave lets businesses create an account and start accepting payments without paying a developer fee to Flutterwave.

So why can a developer still quote ₦200,000, ₦500,000 or more to “integrate payment”?

Because the gateway fee and the engineering work are different things.

The gateway charges for processing transactions. The developer is being paid to make your website or application behave correctly before, during and after those transactions.

For 2026 planning, I would use these bands:

These are planning ranges for development work, not fees published by Paystack or Flutterwave.

The useful question is not:

How much does it cost to add a Paystack button?

It is:

What business state must change safely after money moves?

That is where the real engineering begins.

First, separate three different payment costs

A buyer should keep these lines separate.

1. Gateway transaction fee

This is what the payment provider deducts when a customer pays.

2. Development/integration cost

This is what you may pay a developer or agency to connect payment correctly to your website, app, database and business workflow.

3. Ongoing operating cost

This can include maintenance, monitoring, accounting/reconciliation work, messaging and any supporting infrastructure.

Confusing these categories makes quotes look contradictory when they are not.

Paystack can truthfully say zero integration fee while a developer charges you to build the integration.

Paystack’s current Nigeria pricing

As of October 2026, Paystack’s official pricing page lists:

Local transactions

1.5% + ₦100

The ₦100 component is waived for transactions below ₦2,500, and local fees are capped at ₦2,000 per transaction.

International transactions

Paystack lists standard international Mastercard, Visa and Verve transactions at 3.9% + ₦100. Its support documentation lists different pricing for some channels such as American Express.

Paystack also states that there is zero integration fee and zero maintenance fee from Paystack itself.

Source: Paystack pricing and Paystack transaction pricing.

Those numbers are gateway economics.

They do not define your software-development scope.

Flutterwave’s current Nigeria pricing

Flutterwave’s official Nigeria pricing page currently lists:

Local collections

2% per transaction across local payment methods, shown as:

• 1.4% transaction fee;
• 0.6% platform fee.

International transactions

4.8% per transaction.

Flutterwave states that transaction fees are subject to 7.5% VAT.

Source: Flutterwave Nigeria pricing.

Again, this is what the processor charges for moving money.

The website still needs to know what to do with that payment.

A payment button is the easy part

A basic integration can often initialize a checkout session quickly.

The difficult part begins after the user clicks Pay.

Your system needs to answer:

• Which order or booking does this payment belong to?
• Which amount is expected?
• Which currency is valid?
• Has this reference already been processed?
• Did the gateway really receive the money?
• Has the customer already received the service/product effect?
• What happens if a callback arrives twice?
• What happens if the callback arrives ten minutes late?
• What happens if the browser says success but server verification says otherwise?
• What happens if a refund is issued later?

The checkout interface may be one component.

The financial state around it can touch the entire business workflow.

Do not trust the browser redirect as payment proof

A normal hosted checkout sends the customer back to your site after payment.

That redirect is useful for customer experience.

It should not be your only authoritative payment signal.

The user can:

• close the browser before redirect;
• lose internet connection;
• revisit the success URL;
• alter query parameters;
• trigger the frontend flow more than once.

The backend should verify the transaction directly with the gateway or process a trusted signed event/webhook according to the provider’s integration model.

Then your own database decides whether the business action has already happened.

This is the difference between showing a success page and recording a trustworthy payment.

Webhooks make the payment flow asynchronous

A webhook is the provider sending your server an event when something happens.

That can include a successful charge, transfer or another payment-state event depending on the gateway.

This is useful because the event does not depend on the customer’s browser finishing its journey.

But webhooks create engineering responsibilities:

• verify that the event came from the gateway;
• handle the event only once even if delivered multiple times;
• record failures;
• retry safely where appropriate;
• match the external reference to your internal transaction;
• reject unexpected amounts/currencies/states;
• keep an audit trail.

A developer who says “Paystack already handles that” is describing the gateway side, not your application’s side.

Idempotency prevents one payment from creating two business effects

Suppose a payment-success webhook arrives twice.

If your code responds by:

1. marking the order paid;
2. reducing stock;
3. issuing a ticket;
4. sending a receipt;
5. creating a commission;

then blindly processing the event twice can create duplicate effects.

The payment reference should be handled idempotently: the same confirmed payment can be seen repeatedly without creating the same business event again.

This matters for:

• ecommerce orders;
• event tickets;
• bookings;
• subscriptions;
• digital downloads;
• wallet credits;
• marketplace commissions.

I cover this failure mode more deeply in why payment webhooks create duplicate orders.

The amount should come from the server, not from a trusted-looking screen

If the business sells a product for ₦50,000, the browser should not be allowed to decide that the expected amount is ₦5,000 simply because a hidden field says so.

For production payment flows, the backend should derive or validate the expected amount from trusted business data.

That can include:

• order items;
• booking deposit rules;
• subscription plan;
• invoice balance;
• currency;
• discounts;
• taxes/fees where relevant.

Then verification compares what the gateway received with what the business expected.

This is especially important once the payment amount depends on database state rather than one fixed button.

Simple ecommerce integration: what should be in scope?

For a straightforward online store, I would normally expect:

1. order created in a pending/unpaid state;
2. server initializes the payment using the order total;
3. customer is redirected to gateway checkout;
4. customer returns to the store;
5. server verifies transaction independently;
6. trusted gateway event updates payment state;
7. order becomes paid only once;
8. customer receives confirmation/receipt;
9. admin can inspect payment reference;
10. failed/abandoned orders remain distinguishable from paid orders.

That is more work than embedding a checkout script, but it is still a fairly standard integration.

This is the sort of project I would expect around the ₦150,000–₦300,000 range when the surrounding store already exists and is cleanly structured.

Why booking deposits can cost more than normal checkout

A booking deposit has two states that must agree:

• the money;
• the reserved time/resource.

Now you need rules such as:

• hold the slot for 10 minutes while payment is pending;
• release it if payment fails/expires;
• prevent somebody else confirming the same slot;
• mark the booking confirmed after verified payment;
• apply deposit to the final balance;
• preserve payment history after rescheduling;
• handle refund/cancellation policy.

This is why a booking integration can sit in the ₦300,000–₦700,000+ territory even when the gateway API itself is simple.

See my booking website cost guide for the scheduling side of that transaction.

Subscriptions are not just “charge monthly”

Recurring billing adds an ongoing state machine.

The product needs to understand:

• active;
• trial;
• payment due;
• payment failed;
• grace period;
• cancelled;
• expired;
• upgraded;
• downgraded.

And then connect those states to product access.

Questions include:

• Does access stop immediately when a payment fails?
• How many retries happen?
• Can the user change plan mid-cycle?
• How are prorations handled?
• What happens to existing data after cancellation?
• Is there a grace period?
• Which gateway record is authoritative?

That is product engineering, not merely gateway setup.

Marketplace payments are another category entirely

A marketplace may collect money from a buyer and owe portions to:

• a seller;
• a service provider;
• the platform;
• a tax/fee account;
• another partner.

Now the system has to reason about balances and payouts.

If funds are split or paid out later, I would want explicit records for:

• gross payment;
• gateway fee;
• platform fee;
• provider entitlement;
• refunds;
• payout status;
• settlement reference.

Do not model a marketplace by storing one paid = true field on the order.

At that point, you are building a financial ledger boundary and the budget should reflect it.

Multiple gateways can improve resilience but double some integration surface

Some businesses want both Paystack and Flutterwave.

Reasons can include:

• payment-channel coverage;
• operational fallback;
• customer preference;
• international requirements.

That can be reasonable.

But the application should not become two unrelated payment systems.

Ideally your internal payment model remains provider-neutral:

• internal payment ID;
• provider;
• provider reference;
• expected amount;
• currency;
• status;
• verified time;
• refunded amount;
• order/booking link.

Then Paystack and Flutterwave are adapters around the same business concept.

This increases initial engineering but reduces chaos when you add or replace a provider later.

Refunds deserve first-class state

A refund is not “delete the payment.”

The payment happened historically.

The refund is another event attached to it.

A useful data model distinguishes:

• paid amount;
• refunded amount;
• refund reason;
• refund reference;
• pending/processed/failed refund state;
• resulting order/booking state.

This matters for customer support and accounting.

If your business expects cancellations, include refund handling in the original quote instead of treating it as a future edge case.

Reconciliation is what tells you whether your database agrees with the gateway

Even a good webhook system can experience delays, outages or implementation bugs.

Reconciliation asks:

For the transactions we believe are paid, does the gateway agree—and for gateway transactions that succeeded, did our system record the business effect?

A small business may handle this through an admin page and manual checks.

A larger operation may automate reconciliation using settlement or transaction APIs.

The level you need depends on transaction volume and consequence.

The point is that webhooks are not accounting.

A production payment system needs a way to detect disagreement.

Logging is part of payment support

When a customer says:

I paid but my order still says pending.

support should be able to answer without asking the customer to pay again.

Useful payment diagnostics include:

• internal order/booking ID;
• payment reference;
• initialization timestamp;
• verification result;
• webhook/event log;
• current payment state;
• current order state;
• settlement/refund state where relevant.

Do not log card details or sensitive credentials.

Log the identifiers and state transitions needed to investigate safely.

What should a ₦300,000–₦700,000 integration include?

For an established Nigerian business application, I would expect a serious payment scope to state whether it includes:

• provider account/configuration guidance;
• server-side initialization;
• trusted amount calculation;
• hosted/inline checkout;
• callback/success/failure UX;
• server-side verification;
• webhook signature validation;
• idempotent event processing;
• internal payment table;
• order/booking state transitions;
• refund support where required;
• admin payment visibility;
• error logging;
• test-mode validation;
• live-mode verification;
• documentation/handoff.

If several of these are missing, the quote may be for a simpler integration.

That can still be the right purchase—just compare the same scope.

Gateway choice should follow the business, not developer preference

Paystack and Flutterwave both support Nigerian online collections and multiple payment methods.

The better fit can depend on:

• your customer geography;
• currencies;
• channels;
• settlement requirements;
• subscriptions;
• transfers/payouts;
• available APIs/features;
• account approval;
• support experience;
• your existing stack.

The developer should be able to explain the trade-off without making the product unnecessarily dependent on one vendor.

In your application architecture, the business rules should belong to you.

The gateway should remain the payment processor.

Hidden costs after integration

Budget for more than the original coding fee.

Depending on the product, ongoing costs can include:

• transaction fees;
• VAT on provider fees where applicable;
• SMS/email receipts;
• hosting/server functions;
• monitoring;
• maintenance;
• chargeback/dispute administration;
• accounting/reconciliation time;
• future API changes.

The largest recurring payment cost is usually transaction fees, which scale with revenue.

That is healthy if the gross margin supports it.

How I would compare two Nigerian payment-integration quotes

Ask both providers:

1. Is the checkout amount generated/validated server-side?
2. What creates the internal payment reference?
3. Is payment verified independently of the browser redirect?
4. Are webhooks used?
5. How is the webhook authenticated?
6. Can the same webhook be processed twice safely?
7. What happens if the customer pays but the callback is delayed?
8. What happens after failed or abandoned payment?
9. Are refunds in scope?
10. Is reconciliation in scope?
11. Can support/admin see payment references and status?
12. Are test and live modes both validated?
13. Who owns the Paystack/Flutterwave account?
14. Where are secret keys stored?
15. What logs exist when something fails?
16. What is considered a new feature outside this payment scope?

Those answers explain why a ₦150,000 integration and a ₦600,000 integration may be different products rather than one provider overcharging.

The right payment integration protects the business effect

Customers do not care that your webhook architecture is elegant.

They care that:

• they are charged the right amount;
• they are not charged twice;
• the order or booking updates correctly;
• they receive what they paid for;
• refunds are traceable;
• support can resolve a problem quickly.

That is what the engineering budget is paying for.

If you are adding Paystack, Flutterwave or another payment gateway to a Nigerian website or application and want the workflow scoped beyond the checkout button, see my MVP development service, ecommerce website cost guide, or send me the transaction flow. I can help map the payment states before they become production bugs.

Sources checked

• Paystack pricing
• Paystack transaction pricing
• Flutterwave Nigeria pricing