South African and Pakistani merchants running ERPNext hit the same wall: the platform's native payment options (Stripe, PayPal, Razorpay, Braintree, Paytm) don't cover PayFast, so ZAR and PKR customers can't pay through the Frappe web checkout with the methods they actually use — cards, instant EFT, or mobile wallets. Teams end up marking Sales Invoices paid by hand from bank statements, chasing PayFast's transaction console in a separate tab, and reconciling settlement batches in a spreadsheet. There is no PayFast option in the Payment Gateway Account list, so Payment Request emails and the portal "Pay Now" button simply don't route to PayFast at all.

We build a proper Frappe app — erpnext_payfast — that registers PayFast as a first-class ERPNext payment gateway. It ships a PayFast Settings single DocType (holding merchant ID, merchant key, passphrase, sandbox/live toggle, and per-currency enablement) with credentials stored as Password fields, and it hooks into ERPNext's standard Payment Gateway / Payment Request flow so any Sales Invoice, Sales Order, or web-portal document can generate a PayFast "Pay Now" link. When a customer clicks it, a whitelisted method (erpnext_payfast.api.initiate) builds the signed PayFast form payload — MD5 signature over the sorted field set plus passphrase — and redirects to the hosted PayFast payment page, so no card data ever touches your ERPNext instance.

On the return path, a whitelisted, allow_guest ITN endpoint (erpnext_payfast.api.itn) receives PayFast's Instant Transaction Notification, validates it four ways per PayFast's spec — signature match, source-IP allowlist, amount-equals-expected, and a server-side postback confirmation to PayFast — then, inside a single transaction, creates the Payment Entry, links it to the originating Payment Request and reference document, and updates status. hooks.py doc events keep the Payment Request and invoice in sync, a scheduler_event sweeps for pending/timed-out transactions and pulls settlement data so bank reconciliation matches, and refunds are handled through a guarded server-side action that calls the PayFast API and books the reversing Payment Entry. Recurring subscriptions map PayFast tokenization/subscription billing onto ERPNext Subscription records. Role and permission handling reuses ERPNext's Accounts Manager / Accounts User profiles so who can configure the gateway and who can issue refunds is governed by standard permissions, and every gateway call is written to a log DocType for audit. Client scripts surface the PayFast status and a "Retry / Refund" control directly on the Sales Invoice and Payment Request forms.

Because this is build-to-order, nothing is shipped from a shelf. You start with a short scoping call; we confirm which currencies and methods you need (cards, instant EFT, wallet, recurring), your ERPNext version (v15 or v16), and your reconciliation and refund rules. We build against a copy of your setup, run UAT on a staging bench with PayFast sandbox credentials, then install on your production bench, hand over the git repository, and stay on for a post-go-live support window. Typical delivery is one working week from confirmed scope.