GCC retailers running ERPNext consistently lose cart conversion and average order value at the payment step: shoppers in the UAE and Saudi Arabia now expect a Tabby "Pay in 4" option, and when they don't see it they abandon or downsize the basket. ERPNext core ships card and generic payment-gateway integrations, but it has no native concept of a Buy-Now-Pay-Later provider — no pre-checkout eligibility scoring, no product/cart promotional messaging ("or 4 payments of AED X"), and no way to reconcile a BNPL settlement that is captured, partially refunded, or clawed back on a schedule that differs from the sale document. Bolting this onto ERPNext with ad-hoc client scripts creates silent reconciliation gaps that surface as unbalanced payment entries weeks later.

We build a proper Frappe application — erpnext_tabby — installed on your bench as a versioned app, not a pile of loose customizations. It introduces its own module and DocTypes: a Tabby Settings single DocType (holding public/secret API keys, merchant code, environment toggle, and currency/locale config, with secrets stored as Password fieldtype), a Tabby Session DocType logging every checkout session and its provider ID, and a Tabby Webhook Log DocType for idempotent event capture and replay. The checkout flow calls Tabby's pre-scoring endpoint through whitelisted server methods (@frappe.whitelist()) so the browser never touches your secret key; eligibility results and installment plans are returned to the storefront via the Frappe REST API. On the web storefront we register client scripts and Website-level assets that render Tabby's promo snippet on product and cart pages, honoring the shopper's cart total and locale.

The lifecycle is wired through hooks.py document events and scheduler hooks. When a Sales Order or Sales Invoice is submitted against a Tabby session, on_submit doc events create and reconcile the corresponding Payment Entry; capture, refund, and cancellation each map to the correct accounting document so your general ledger always ties out. Tabby's asynchronous settlement is handled by a whitelisted webhook endpoint that verifies the signature, writes to Tabby Webhook Log with a dedupe key (so retries are idempotent), and updates the linked sale document's status. A scheduler_events hourly job reconciles any sessions that were authorized but whose webhook never arrived, closing the gap between "customer paid Tabby" and "ERPNext knows about it." Access is governed by a dedicated role and role profile so only finance and store-admin users can view keys or trigger manual refunds, and all sensitive actions are captured in the standard Frappe audit trail.

Because this is build-to-order, nothing ships as a blind download. We start with a scoping call to confirm your ERPNext version (v15 or v16), storefront setup, Tabby merchant account, currencies, and reconciliation rules, then build against a staging copy of your instance. You review the working integration in UAT before we touch production. Typical delivery is one working week from confirmed scope. You receive the full app source in a git repository you own, installed and configured on your bench, with documentation, a training session, and a post-go-live support window — no vendor lock-in and no black box.