Pan-African ERPNext merchants routinely hit a wall at checkout. ERPNext ships integrations for a handful of global processors, but none of them cover the payment methods your customers in Nigeria, Ghana, Kenya, or Cote d'Ivoire actually use — M-Pesa and other mobile money wallets, USSD, and local bank transfers settled in naira, cedi, shilling, or franc. Without Flutterwave, you are stuck routing African customers through card-only rails that decline constantly, reconciling settlements by hand, and manually marking Sales Invoices as paid. The Payment Gateway and Payment Request DocTypes are present, but the connector that ties them to Flutterwave's collections and settlement flows is not.

We build a proper Frappe app — erpnext_flutterwave — that installs cleanly onto your bench and registers as a first-class ERPNext payment gateway. It introduces a Flutterwave Settings single DocType for your public key, secret key, and encryption/webhook secret (stored via Frappe's Password fieldtype, never in plaintext), plus a Flutterwave Transaction DocType that logs every charge along with its tx_ref, flw_ref, currency, and lifecycle status. When a customer pays a Payment Request, the app initializes a Flutterwave Standard checkout, presents cards, mobile money, USSD, and bank-transfer options in the customer's local currency, and returns them to your site.

Technically, the flow is closed by a whitelisted webhook endpoint (@frappe.whitelist(allow_guest=True)) that verifies the verif-hash signature against your stored secret, re-verifies the transaction server-side against Flutterwave's /transactions/:id/verify endpoint, and only then triggers the standard on_payment_authorized path — creating the Payment Entry and reconciling it against the originating Sales Invoice via Frappe doc events in hooks.py. For recurring revenue we store Flutterwave card tokens against a Flutterwave Customer Token DocType and drive Payment Plans and subscription renewals from a scheduler event (scheduler_events in hooks.py), charging tokenized cards on their due date and writing the result back to ERPNext. Idempotency keys and a status-reconciliation scheduler protect against duplicate or missed webhooks, and role-scoped permissions keep gateway configuration to Accounts Manager while exposing read-only transaction views to your finance team.

Because this is a build-to-order product, nothing ships until we agree on scope. We start with a short scoping call to confirm your currencies, payment methods, ERPNext/Frappe version (v15 or v16), and whether you need subscriptions or one-off collections only. We then build against your requirements, deliver on a staging bench for UAT, and go live with your keys. Typical delivery is 2-4 weeks from confirmed scope, and you receive the full app source code and git repository so you are never locked to us.