A build-to-order Frappe app that wires MyFatoorah's unified GCC checkout into ERPNext, so KNET, mada, Benefit, and card payments reconcile straight to confirmed Payment Entries. ECOSIRE scopes, builds, installs, and supports it for your ERPNext v15/v16 site. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A build-to-order Frappe app that wires MyFatoorah's unified GCC checkout into ERPNext, so KNET, mada, Benefit, and card payments reconcile straight to confirmed Payment Entries. ECOSIRE scopes, builds, installs, and supports it for your ERPNext v15/v16 site.
Sin pago ahora. Esto envía una solicitud de presupuesto a nuestro equipo; te responderemos por correo con precios y próximos pasos.
GCC merchants running ERPNext quickly hit a wall at checkout: buyers expect KNET in Kuwait, mada in Saudi Arabia, and Benefit in Bahrain, but ERPNext core ships payment integrations aimed at global card gateways, not the local aggregators and debit rails that dominate the region. Teams end up reconciling MyFatoorah settlements by hand, exporting CSVs, and re-keying references against Sales Invoices — which is slow, error-prone, and breaks the moment volume grows. ERPNext's built-in Payment Gateway framework simply does not speak MyFatoorah's InitiatePayment/ExecutePayment API or its webhook contract out of the box.
MyFatoorah unified InitiatePayment/ExecutePayment checkout wired into ERPNext via whitelisted server methods that return a hosted payment redirect URL
KNET, mada, Benefit, Apple Pay, and Visa/Mastercard card support surfaced from MyFatoorah's enabled payment-method IDs configurable per environment
Signature-verified webhook endpoint (@frappe.whitelist(allow_guest=True)) that validates the MyFatoorah callback before touching any financial document
Idempotent auto-creation and submission of a Payment Entry against the matching Sales Invoice, keyed to a MyFatoorah Transaction DocType to prevent duplicate postings on webhook retries
MyFatoorah Settings single DocType with test/live base-URL toggle and API token stored via Frappe get_password, never in plaintext
Refund handling that calls MyFatoorah's refund API from ERPNext and records status, refund ID, and amount back to the transaction
We build a proper Frappe app (its own module, DocTypes, and hooks.py) that integrates MyFatoorah as a first-class payment method inside ERPNext. A MyFatoorah Settings single DocType holds your API token, base URL (test vs live), and enabled payment-method IDs, with the secret stored via Frappe's get_password so it never sits in plaintext. When an invoice or web-shop order needs payment, whitelisted server methods call MyFatoorah's unified checkout to create a hosted payment session and return the redirect URL; the customer pays via KNET, mada, Benefit, or card, and MyFatoorah drives the result back to a whitelisted webhook endpoint on your site.
Technically, the confirmation path is idempotent and signature-verified. The webhook (a @frappe.whitelist(allow_guest=True) method) validates the MyFatoorah signature, looks up the originating transaction in a MyFatoorah Transaction DocType, and — only on a genuinely paid status — creates and submits a Payment Entry against the correct Sales Invoice, writing back the payment ID, method, and settled amount for clean reconciliation. Refunds issued from ERPNext call MyFatoorah's refund API and record the outcome, and multi-currency orders are mapped to the right MyFatoorah currency and account. A scheduler event (scheduler_events in hooks.py) reconciles any transactions whose webhook was missed by polling GetPaymentStatus, so a dropped callback never leaves an invoice silently unpaid. Roles and permissions are scoped through a dedicated role profile so only finance staff can view tokens or trigger refunds, and everything is exposed through the standard Frappe REST API for your other systems.
Because this is build-to-order, we start from your actual scope — which entities pay (Sales Invoice, POS, web-shop, or a custom flow), which GCC methods and currencies you need, and your MyFatoorah account tier. ECOSIRE writes the code, tests it against your MyFatoorah test credentials on a staging bench, runs UAT with you, and then installs it on your production ERPNext v15 or v16 site with a rollback plan. You receive the full source as an installable app and the Git repository, so you are never locked to us. Typical delivery is 2 to 4 weeks from confirmed scope.
Runs an online store selling into Kuwait, Saudi Arabia, or Bahrain and needs one aggregator that covers KNET, mada, and Benefit alongside cards, with orders auto-reconciled to Sales Invoices instead of manual settlement matching.
Owns the AR close and wants every MyFatoorah settlement to land as a confirmed Payment Entry against the right invoice, with a full audit trail and reliable refunds, so month-end stops depending on spreadsheet exports.
Delivering ERPNext for a regional client and needs a production-grade, source-included MyFatoorah integration on v15/v16 that follows Frappe conventions (DocTypes, hooks, whitelisted methods) and can be handed over cleanly via Git.
Sells across GCC markets in KWD, SAR, BHD, and AED and needs currency-correct payment sessions and receivable-account routing so each entity's books stay clean without custom scripting.
Compre la licencia en ecosire.com y descargue la aplicación ZIP de ERPNext MyFatoorah Connector desde el panel de su cuenta.
Extraiga el ZIP en la carpeta de aplicaciones de su banco o ejecute `bench get-app` con la ruta a la aplicación extraída.
Ejecute `bench --site SITE_NAME install-app APP_NAME` seguido de `bench migrar` para instalar ERPNext MyFatoorah Connector y aplicar su esquema.
Abra la configuración de licencia de ECOSIRE en su sitio y active su clave de licencia. Requiere las aplicaciones gratuitas ecosire_connect y ecosire_license_client.
| Criterio | ECOSIRE | Construcción personalizada | Competidor | Odoo Nativo |
|---|---|---|---|---|
| GCC methods (KNET/mada/Benefit) | All enabled via MyFatoorah aggregator, configurable per environment | Possible but you build each rail and its edge cases yourself | Often card-only or a single method; GCC coverage varies | |
| Payment confirmation | Signature-verified webhook + idempotent Payment Entry, plus scheduler reconciliation for missed callbacks | Depends entirely on your build; retries and idempotency easy to miss | Basic webhook; reconciliation depth varies | |
| Refund handling | Issued from ERPNext via MyFatoorah refund API with recorded status | Must be coded and tested from scratch | Sometimes present, sometimes manual in the MyFatoorah portal | |
| Multi-currency | Currency mapping + per-currency receivable account routing | Achievable with extra development effort | Often single-currency or limited | |
| Frappe conventions | Proper app, DocTypes, hooks.py events, whitelisted methods, role profiles | Quality depends on your developer's Frappe expertise | Usually conventional, but internals and quality are opaque | |
| Source ownership | Full source + Git repo handover, no runtime lock | You own it, but you also carry all the build cost | Often closed source or license-gated | |
| Support & version upgrades | Post-go-live window + optional maintenance for v15/v16 upgrades | Entirely your team's responsibility | Varies by vendor; may lag ERPNext releases | |
| Time to production | Typically 2-4 weeks from confirmed scope, built and tested for you | Often months, plus your team's ramp-up on MyFatoorah's API | Fast if it fits, but gaps force custom work anyway |
This is a build-to-order app, not an instant download. Typical delivery is 2 to 4 weeks from confirmed scope, depending on how many payment flows (Sales Invoice, POS, web-shop, custom), currencies, and edge cases are involved. After a short scoping call we give you a firm timeline and a fixed milestone plan before any build starts.
No. ECOSIRE builds, tests, and installs this connector specifically for your ERPNext site and MyFatoorah account. You receive it as a standard installable Frappe app plus the Git repository, so it deploys via bench like any Frappe app and you fully own the code.
We support Frappe/ERPNext v15 and v16. Through MyFatoorah's unified checkout the connector can enable KNET, mada, Benefit, Apple Pay, and Visa/Mastercard cards — you choose which methods are active per environment, and we configure them against your MyFatoorah test and live credentials.
MyFatoorah calls a signature-verified webhook on your site. Only on a genuinely paid status does the app create and submit a Payment Entry against the matching Sales Invoice, keyed to a MyFatoorah Transaction record so webhook retries never double-post. A scheduler event also polls GetPaymentStatus to catch any missed callback, so no paid invoice is left unreconciled.
Refunds are issued from ERPNext via MyFatoorah's refund API, with status and refund ID recorded on the transaction. Multi-currency orders are mapped to the correct MyFatoorah currency and routed to the right receivable account, so KWD, SAR, BHD, and AED transactions keep your books accurate.
Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because you receive the full source and Git repository, your own team can extend it too. Ongoing maintenance — new MyFatoorah methods, ERPNext version upgrades, or feature additions — is available as a separate support agreement.
You own it. We hand over the complete Git repository and the installable app for your scoped version. There is no runtime license lock and no dependency on our servers — the connector runs entirely on your ERPNext bench.
A build-to-order Frappe app that wires MyFatoorah's unified GCC checkout into ERPNext, so KNET, mada, Benefit, and card payments reconcile straight to confirmed Payment Entries. ECOSIRE scopes, builds, installs, and supports it for your ERPNext v15/v16 site.