A build-to-order HyperPay acquiring integration for ERPNext covering mada, Visa, Mastercard, Amex, Apple Pay and STC Pay via COPYandPAY and Server-to-Server, with 3-D Secure 2 and tokenized recurring payments. ECOSIRE scopes, builds, installs and supports it on your bench. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $299.00 USD; request a quote for a scoped proposal.

A build-to-order HyperPay acquiring integration for ERPNext covering mada, Visa, Mastercard, Amex, Apple Pay and STC Pay via COPYandPAY and Server-to-Server, with 3-D Secure 2 and tokenized recurring payments. ECOSIRE scopes, builds, installs and supports it on your bench.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
Middle East ERPNext merchants keep hitting the same wall: ERPNext core ships Stripe, PayPal, Razorpay, Braintree and a couple of others out of the box, but nothing for HyperPay — the acquirer most Saudi, Jordanian and UAE banks actually settle through. That means no mada support, no Apple Pay or STC Pay at checkout, no local 3-D Secure 2 flow, and no clean way to reconcile HyperPay settlements against your Payment Entry and Sales Invoice records. Teams end up bolting on a hosted payment page in a separate system and re-keying transactions, which breaks the audit trail ERPNext is supposed to give you.
HyperPay registered as a native ERPNext Payment Gateway with a `Payment Gateway Account` for automatic bank/clearing-account reconciliation
COPYandPAY widget checkout via `/v1/checkouts` plus a Server-to-Server API path for fully custom, PCI-scoped-down flows
mada, Visa, Mastercard and Amex acceptance through per-brand HyperPay entity IDs configurable in `HyperPay Settings`
Apple Pay and STC Pay wallet support wired into the same checkout return handler
3-D Secure 2 SCA challenge handled by HyperPay and re-verified server-side before any `Payment Entry` is created
Tokenized recurring billing: initial `registrationId` stored per customer, charged on a `scheduler_events` cron with MERCHANT-initiated transactions
We build a proper Frappe app — erpnext_hyperpay — that registers HyperPay as a first-class Payment Gateway inside ERPNext rather than a script pasted into a Web Form. It ships a HyperPay Settings DocType (single) holding your entity IDs per brand (mada, VISA/MASTER, Apple Pay, STC Pay), access token and mode, with credentials encrypted via Frappe's get_password/password fieldtype so they never sit in plain text. A Payment Request routes through the gateway controller, which prepares a checkout against HyperPay's /v1/checkouts endpoint and renders the COPYandPAY widget, or drives the Server-to-Server API where you need a fully custom checkout. The success return hits a @frappe.whitelist(allow_guest=True) method that queries the payment status endpoint, verifies the resultCode, and on approval creates or submits the Payment Entry and marks the linked invoice — all inside a single database transaction so a half-recorded payment can't happen.
Technically it is wired the ERPNext way. hooks.py doc events keep Sales Invoice and Payment Request in sync; a Payment Gateway Account links the gateway to the right bank/clearing account so reconciliation is automatic. 3-D Secure 2 SCA is handled by HyperPay's flow and the challenge result is validated server-side before we trust it. For subscriptions and saved cards we implement registration tokens: the initial COPYandPAY run stores a HyperPay registrationId on a child table against the customer, and a scheduler_events (cron/daily) hook charges tokenized initiator=MERCHANT transactions for recurring billing, writing each result back as a Payment Entry with full idempotency guards so a retried scheduler run never double-charges. Webhooks (where your HyperPay account has them enabled) are received on a signed, whitelisted endpoint and verified before any ledger write. Everything respects Frappe permissions — a dedicated HyperPay Manager role profile gates Settings and the manual-capture/refund actions, and all API calls are logged for audit.
Because this is build-to-order, nothing ships until we agree scope. After a short scoping call we confirm which brands and flows you need (COPYandPAY vs Server-to-Server, recurring yes/no, refund/capture handling), your ERPNext version (v15 or v16) and hosting, then build against a staging copy of your bench. You get UAT on staging with test-mode HyperPay credentials, a documented go-live cutover, and the full source repo handed to you. Typical delivery is 2-4 weeks from confirmed scope, and we support the app through a post-go-live window with a clear path for updates as HyperPay's API and your ERPNext version evolve.
Runs sales through ERPNext and must accept mada, Apple Pay and STC Pay to convert local shoppers. Needs SAMA-aligned local acquiring through HyperPay with payments reconciled straight into `Payment Entry`, not a disconnected hosted page.
Operates across the Levant and GCC and settles through HyperPay for Visa, Mastercard and Amex. Wants one ERPNext integration handling multiple brand entity IDs and currencies with 3-D Secure 2 enforced end to end.
Bills customers on a schedule and needs tokenized cards. Requires HyperPay `registrationId` storage and a reliable scheduler-driven charge that writes idempotent `Payment Entry` records without double-charging on retries.
Owns the bench and cares about maintainability. Wants a clean Frappe app with proper hooks, role profiles and encrypted credentials, plus the source repo and docs so the team can support and extend it after handover.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 HyperPay Payment Gateway for ERPNext 应用程序 ZIP。
将 ZIP 解压到您的 bench 的 apps 文件夹中,或者使用解压缩的应用程序的路径运行“bench get-app”。
运行 `bench --site SITE_NAME install-app APP_NAME`,然后运行 `bench migrate` 以安装 HyperPay Payment Gateway for ERPNext 并应用其架构。
打开您站点上的 ECOSIRE 许可证设置并激活您的许可证密钥。需要免费的 ecosire_connect 和 ecosire_license_client 应用程序。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| HyperPay support in ERPNext | Native gateway with mada, wallets, S2S and tokenization | Whatever you build and maintain yourself | Rare; most Frappe apps target Razorpay/Stripe | |
| mada / Apple Pay / STC Pay | All wired via per-brand entity IDs | Possible but you integrate each brand | Usually card-only, no local wallets | |
| Recurring / tokenized billing | `registrationId` tokens + idempotent scheduler charge | Must design token store and cron safely | Often absent or one-off charges only | |
| 3-D Secure 2 SCA | Enforced and re-verified server-side | Depends on your implementation | Varies; often not verified server-side | |
| ERPNext reconciliation | Payment Gateway Account → auto `Payment Entry` | You wire the accounting yourself | Basic, may need manual matching | |
| Version fit (v15/v16) | Pinned to your exact version at build | Your team tracks compatibility | Generic; may lag your version | |
| Source & ownership | Full git repo handed over | You own it but built it | Vendor-controlled, often closed | |
| Support & updates | Post-go-live window + update engagements | Entirely on your team | Best-effort marketplace support |
This is build-to-order, not an instant download. Typical delivery is 2-4 weeks from confirmed scope. After a short scoping call we lock the brands, flows and ERPNext version, build against a staging copy of your bench, run UAT with HyperPay test credentials, then schedule the go-live cutover. Timeline moves with scope — recurring tokenization and Server-to-Server flows add effort versus a COPYandPAY-only build.
Every build includes a post-go-live support window for defect fixes and configuration help, and you receive the full git repository so your team can maintain it. As HyperPay evolves its API or you upgrade ERPNext, we offer update engagements to keep the app current. Because you own the source, you are never locked to us.
We build for Frappe/ERPNext `v15` and `v16`. We confirm your exact version and bench setup during scoping and pin the app to it, so the DocTypes, hooks and Payment Gateway wiring match your instance rather than a generic target.
Yes, when it is in scope. The initial COPYandPAY checkout stores a HyperPay `registrationId` against the customer, and a `scheduler_events` cron job charges MERCHANT-initiated tokenized transactions for subscriptions, writing each result back as an idempotent `Payment Entry` so retries never double-charge.
No. ECOSIRE builds, installs and supports this specifically for you — it is not a public marketplace download. That means it is tailored to your brands, currencies, ERPNext version and reconciliation setup rather than a one-size-fits-all package.
Access tokens and entity IDs live in a `HyperPay Settings` single DocType using Frappe's password fieldtype and `get_password`, so they are encrypted at rest and never stored in plain text or committed to the repo. Access is gated by a dedicated `HyperPay Manager` role profile.
Yes. HyperPay is registered as a proper Payment Gateway with a linked `Payment Gateway Account`, so approved transactions create submitted `Payment Entry` records against the correct bank/clearing account and mark the linked `Sales Invoice`, keeping your ledger and audit trail intact.
A build-to-order HyperPay acquiring integration for ERPNext covering mada, Visa, Mastercard, Amex, Apple Pay and STC Pay via COPYandPAY and Server-to-Server, with 3-D Secure 2 and tokenized recurring payments. ECOSIRE scopes, builds, installs and supports it on your bench.