Source Code Self-hosted Payment Gateway QRIS GoPay Merchant

This source code provides a fully self-hosted payment gateway solution built on top of a GoPay Merchant account. Built with Node.js and Fastify, the system generates dynamic QRIS codes on demand, detects settlement automatically through GoPay Merchant's official API, and delivers signed webhook callbacks to your backend the moment a payment is confirmed — making it a complete, self-contained alternative to third-party payment gateways. Unlike solutions built on browser automation or scraping, this tool communicates directly with GoPay Merchant's official API for authentication, QRIS generation, and settlement detection. This design choice results in significantly better stability, lower resource consumption, and a much lower operational risk profile compared to systems that depend on simulating browser sessions against a banking or e-wallet platform. Every detected payment automatically triggers a signed webhook to your configured endpoint, delivered as structured JSON with an HMAC-SHA256 signature and an event header identifying whether the transaction was paid or expired. This makes it straightforward to integrate with any existing checkout flow, deposit automation pipeline, or internal back-office system without additional data transformation. The system also handles GoPay Merchant authentication transparently. If the stored session token is missing or has expired, the backend automatically re-authenticates and refreshes the token before the next scheduled check — with no manual re-login required, and without terminating any other active session on the same GoPay Merchant account. This means the account remains fully usable on a mobile device or elsewhere while the self-hosted system operates in the background. Who This Product Is Built For This self-hosted QRIS payment gateway is designed for developers and businesses who want to accept QRIS payments through their own infrastructure, without paying a per-transaction fee to a third-party payment gateway provider. Whether you are running a SaaS platform, a digital top-up service, or an internal finance system, this source code gives you the full infrastructure needed to generate, monitor, and confirm QRIS payments end-to-end. If you operate a platform where users pay for goods, services, or subscriptions, relying entirely on a third-party payment gateway means recurring transaction fees that scale with your revenue. This source code eliminates that dependency by giving you a payment gateway you fully own and control, running on your own server, connected directly to your own GoPay Merchant account. Game top-up platforms, digital voucher sellers, and e-wallet reseller services benefit significantly from this kind of setup. When a customer initiates a payment, the system generates a unique dynamic QRIS instantly via API, detects the settlement once the customer completes the scan-and-pay flow, and pushes a signed webhook to your backend — allowing your platform to fulfill the order automatically without any human intervention. SaaS and membership platforms face a similar need. Subscription renewals, one-time upgrades, or credit top-ups can all be handled through the same create-payment-to-webhook flow, giving your platform a fully automated billing experience without integrating a heavier third-party payment provider. Point-of-sale (POS) and cashier systems also benefit from per-transaction dynamic QRIS generation, since each transaction can have its own unique QRIS code with an exact or near-exact amount, simplifying reconciliation and reducing the need for manual matching between orders and incoming payments. Bot-based services — including Telegram, WhatsApp, or Discord bots that accept payments for digital goods, memberships, or credits — are a natural fit, since the webhook-driven architecture allows any bot backend to receive a payment confirmation event and respond immediately, without polling anything manually. How the Payment Flow Works The payment lifecycle follows the same pattern used by conventional payment gateways. A payment is created through the REST API, which immediately returns a dynamic QRIS in both string and PNG form — no waiting period is required before the QRIS is usable. The customer then scans the QRIS and completes the payment through their preferred GoPay/QRIS-compatible application. In the background, an adaptive poller checks for settlement by querying GoPay Merchant's official API directly. This poller is shared across all pending transactions rather than spawning one poller per payment, and it automatically starts as soon as a payment is created and stops once no pending transactions remain — keeping resource usage minimal even under load. Once a matching settlement is detected, the transaction status is updated to "Paid" and a signed webhook is dispatched to your configured endpoint. If a transaction remains unpaid past its expiration window, the system automatically marks it as expired and dispatches a corresponding webhook event, ensuring your backend always has a definitive final state for every transaction — paid or expired — without needing to poll your own database indefinitely. Webhook delivery includes automatic retry handling. If your endpoint does not respond successfully, the system retries up to five times with exponential backoff, logs every attempt, and allows manual resend directly from the admin panel if further intervention is needed. Technical Architecture and Stack The backend runtime is Node.js (ESM) built on Fastify v5, chosen for its low overhead and strong performance characteristics under concurrent request load. The admin panel is built with SvelteKit and Tailwind CSS v4, communicating with the backend through a Backend-for-Frontend (BFF) pattern, meaning session cookies and API keys are never exposed directly to the browser. Data persistence is handled through SQLite in WAL mode via better-sqlite3, chosen for its simplicity and low operational overhead on small-to-medium VPS deployments. The data access layer is storage-agnostic by design, meaning migration to another database engine in the future does not require rewriting business logic. Security is handled through a combination of scrypt for administrator password hashing, SHA-256 for API key hashing, AES-256-GCM for encrypting stored GoPay Merchant tokens, and HMAC-SHA256 for signing outgoing webhook payloads. Administrator login is protected by an IP-based rate limiter to prevent lockout-style denial-of-service attacks, with support for resolving the real client IP behind Cloudflare or another reverse proxy. Real-time updates on the admin panel are delivered through Server-Sent Events (SSE), meaning transaction status changes are reflected instantly without requiring the page to be refreshed or additional polling logic on the frontend. Integration Examples For a Laravel-based platform, integration typically involves creating a webhook route that verifies the HMAC-SHA256 signature, parses the JSON payload, and updates the corresponding order or deposit record based on the payment ID. Because the payment ID is stable and idempotent across retries, duplicate webhook deliveries can be safely treated as no-ops. For a Node.js backend, the integration is direct — the create-payment endpoint can be called from your own checkout logic, and the webhook receiver can live within the same service or as a separate microservice communicating over HTTP. For teams using Python-based backends, a Flask or FastAPI endpoint can receive and verify the webhook payload using the same HMAC-SHA256 signature scheme, with example handler code included in the documentation for Node.js, PHP, and Python. Customization and Support The source code is fully open for modification. Buyers can adjust the webhook payload structure, extend the admin panel, add new payment matching rules, or integrate the system into a larger platform architecture. The codebase is structured with a clear separation between the data access layer, business logic, and the GoPay Merchant API client, making it approachable for developers who are new to the codebase. If customization beyond self-implementation is required — such as adapting the system for a multi-merchant setup, building additional reporting features, or integrating with a specific existing platform — paid customization services are available through direct consultation. Minor updates are included for one year from the date of purchase. Major architectural updates are covered for up to three months from the date of purchase, with continued update availability afterward at an additional cost depending on scope. Technical support for installation and configuration issues is available throughout the support period. Why Choose Aditdev.ID Every product sold through the Aditdev.ID marketplace is built and maintained by Aditama Gilang Farel, an Indonesia-based full-stack developer with extensive hands-on experience in payment infrastructure, backend systems, and SaaS platform development. This is not a resold or repackaged script — it is a product that has been actively developed, versioned, and iterated on from its initial release through multiple major and minor updates. This self-hosted QRIS payment gateway has gone through a complete version history — from its initial release, through security hardening (IP-based rate limiting), a full premium UI/UX overhaul of the admin panel, and a major v2.0.0 tech-stack modernization covering Tailwind CSS v4, Fastify v5, and better-sqlite3 v12. It has also been used for personal production purposes for approximately two months at the time of writing, running without issue. Aditdev.ID specializes in building digital infrastructure for businesses operating in the Indonesian market — including SMM panels, payment automation systems, and SaaS products. This source code reflects a real, recurring problem faced by Indonesian digital businesses: the cost and complexity of relying on third-party payment gateways for QRIS acceptance — solved by giving developers a self-hosted alternative built directly on official GoPay Merchant infrastructure. Understanding GoPay Merchant as a Payment Infrastructure GoPay, one of Indonesia's most widely used e-wallets, offers a merchant product called GoMerch that allows businesses to accept QRIS payments directly. Unlike personal banking platforms that lack an accessible API for individual developers, GoPay Merchant provides an official API surface that this source code integrates with directly for authentication, QRIS generation, and settlement checking. This is a meaningful distinction from browser-automation-based payment tools: because the integration uses GoPay Merchant's own API rather than simulating a browser session, the system does not depend on scraping a web interface that could change without notice, and it does not carry the same operational risk profile associated with automating a login flow through a browser. Because QRIS is a nationally standardized payment method in Indonesia, a self-hosted QRIS gateway built on a GoPay Merchant account can, in practice, accept payments from any QRIS-compatible e-wallet or banking app, not just GoPay itself — making it broadly useful across a wide range of customer payment preferences. Common Use Cases in the Indonesian Digital Economy QRIS has become one of the dominant payment methods for digital transactions in Indonesia, and businesses that want to avoid the recurring per-transaction fees charged by third-party payment gateway aggregators increasingly look toward self-hosted alternatives built directly on merchant accounts they already control. Digital goods and services platforms — including game top-up sites, streaming account resellers, and license/voucher stores — benefit from a checkout flow where a unique QRIS is generated per order, the payment is detected automatically, and the order is fulfilled without manual verification. This removes the scaling bottleneck that manual payment confirmation creates during high-traffic periods. SaaS and subscription-based platforms benefit similarly, using the create-payment-to-webhook flow to automate plan upgrades, renewals, or credit purchases without needing to integrate a heavier, fee-charging third-party payment processor. SMM panel operators and PPOB platforms, which process high transaction volumes for digital top-ups and bill payments, benefit from a payment system that can generate and reconcile large numbers of small transactions automatically, using nominal-based matching with tolerance to avoid ambiguity between concurrent pending payments. Point-of-sale systems and small retail operations benefit from being able to generate a fresh dynamic QRIS for each transaction at the counter, with automatic settlement detection eliminating the need for staff to manually check whether a customer's payment has been received. Deployment Considerations and Best Practices When deploying this system in production, a Linux VPS running PM2 for process management and Nginx as a reverse proxy is the recommended setup, consistent with the documented deployment path. Because the system does not rely on a browser engine, resource requirements are modest compared to automation-based alternatives, and it runs comfortably on low-to-mid-tier VPS instances. The polling interval can be adjusted directly from the admin panel without restarting the underlying process, allowing operators to tune the balance between settlement detection latency and API call frequency based on their transaction volume. Webhook endpoint reliability should be considered on the receiving end. While the system itself retries failed webhook deliveries automatically with exponential backoff, it is good practice for the receiving endpoint to respond quickly and idempotently, since the payment ID remains stable across all retry attempts. Extending the Source Code Because the codebase follows a storage-agnostic data access layer pattern, buyers looking to scale beyond SQLite can migrate to a different database engine without rewriting the core payment logic. This is particularly relevant for platforms expecting significant transaction volume growth over time. Multi-merchant support is a common extension request, where the system is adapted to manage multiple GoPay Merchant accounts under a single deployment, routing payments and webhooks according to which merchant account initiated the transaction. Notification integration is straightforward given the existing webhook architecture. By routing webhook events through a notification dispatcher, operators can send Telegram, WhatsApp, or email alerts for every completed transaction above a certain threshold, which is useful for monitoring high-value payments in real time. Frequently Asked Questions from Developers Developers evaluating this product often ask whether it depends on browser automation in any form. It does not — authentication, QRIS generation, and settlement detection are all performed through GoPay Merchant's official API using native fetch calls, with no headless browser or scraping engine involved anywhere in the system. Another common question concerns session behavior. Because the system uses its own independent authentication session with the GoPay Merchant API, logging in through this source code does not log out or otherwise disturb any other active session on the same account, including the GoMerch mobile app. Developers also ask about token expiration handling. The system automatically detects when the stored session token is missing or expired and performs a fresh login to obtain a new one before the next scheduled settlement check, without requiring any manual intervention. Finally, many buyers ask whether this system can be used for reconciliation or accounting purposes beyond simple payment confirmation. Because every transaction record includes full settlement details from the GoPay Merchant provider response — including fee breakdowns and transaction timestamps — the underlying data can serve as a foundation for building reconciliation reports or accounting exports, though this is not included as a built-in feature. Why Node.js and Fastify Are the Right Choice for Payment Infrastructure When selecting a technology stack for a payment-gateway-adjacent system, request handling performance and low overhead matter directly, since every payment creation and settlement check translates into API calls that need to complete quickly and reliably. Fastify was chosen specifically for its schema-based validation and its position as one of the fastest HTTP frameworks available for Node.js, minimizing overhead on every request in the payment lifecycle. The migration to Fastify v5 in version 2.0.0 aligns the project with the current supported Node.js baseline (v20 and above), ensuring the system continues to receive security and compatibility support as the Node.js ecosystem moves forward, rather than remaining tied to an aging major version. Security Considerations When Running a Self-hosted Payment Gateway Operating a self-hosted payment gateway introduces security responsibilities that should be taken seriously. GoPay Merchant credentials and tokens are stored encrypted using AES-256-GCM rather than in plaintext, and administrator access is protected by password hashing (scrypt) combined with IP-based rate limiting to prevent brute-force or lockout-style attacks. Webhook payloads are signed using HMAC-SHA256, allowing the receiving endpoint to verify that a given webhook truly originated from this system rather than from a spoofed or malicious request — a critical safeguard for any workflow where a webhook event triggers an automatic account credit or order fulfillment. Access to the server running this system should be restricted to authorized personnel only, and standard server hardening practices — SSH key authentication, firewall configuration, and regular security updates — apply here as they would for any production service handling financial transaction data. Aditdev.ID provides this source code as infrastructure for legitimate business use, and buyers are responsible for ensuring their use complies with GoPay Merchant's applicable terms of service.