QGate — Payment Gateway

QGate is the acquiring and payment-gateway component of the QoinPay Enterprise suite. It runs entirely on your own infrastructure under a perpetual license, giving you a single, auditable entry point for accepting card and alternative payments, tokenizing sensitive instrument data, orchestrating 3-D Secure, and reconciling settlement — without routing cardholder data through a third-party SaaS.

This article introduces the QGate architecture, editions, sizing guidance, core modules, and the REST integration surface. For licensing mechanics, see the licensing lifecycle documentation; QGate is entitled and activated the same way as every other module in the suite.

What QGate does

QGate sits between your commerce or billing systems and the payment networks and acquirers you connect to. It accepts an authorization or purchase request, applies your risk and routing policy, exchanges messages with the downstream processor, tokenizes the instrument, and records the transaction for later capture, refund, and settlement. Every state transition is written to an append-only ledger so that your finance and compliance teams can reconstruct the full lifecycle of any payment.

QGate integrates with your systems over the /api/v1 REST surface and signed webhooks.

QGate is payment-method agnostic. Card acquiring (credit, debit, and network-branded prepaid) is handled through pluggable acquirer connectors, while alternative payment methods — bank transfers, wallets, direct debit, and regional real-time-payment rails — are handled through the same connector abstraction. This means a single integration against QGate can present many downstream methods to your merchants or business units.

Core modules

QGate is composed of several cooperating modules, each independently observable and independently scalable:

Authorization engine — validates the request, enforces velocity and amount limits, and drives the message exchange with the selected acquirer connector.
Vault and tokenization — replaces PAN and other sensitive fields with format-preserving or random tokens. The vault is the only component that holds cardholder data at rest, and it is designed to keep the rest of your estate out of PCI DSS scope.
3DS orchestration hooks — QGate does not embed an ACS or a DS, but it exposes lifecycle hooks so you can plug in a 3DS Server (either the bundled connector or your own) to perform frictionless and challenge flows, carrying the authentication result into authorization.
Capture and refund service — manages the money-movement lifecycle after authorization: partial and multiple captures, voids, and full or partial refunds.
Settlement and reconciliation — ingests acquirer settlement files, matches them against the internal ledger, and surfaces exceptions.
Webhook dispatcher — emits signed events to your subscribed endpoints for every material state change.

Tokenization and PCI scope

Tokenization is central to QGate's value on-premise. When a PAN enters the gateway, the vault stores the ciphertext under an envelope-encryption scheme and returns a token that your applications use everywhere else. Because only the vault process — and the storage volume it owns — ever touches cardholder data, the surrounding application, database, and reporting tiers can be kept out of PCI DSS scope. Store the vault's data-encryption keys in an external KMS or HSM where available; QGate references keys by handle rather than holding master key material in application configuration.

POST /api/v1/tokens
{
  "pan": "4111111111111111",
  "exp_month": 12,
  "exp_year": 2029,
  "cardholder_name": "ACME CORP"
}

200 OK
{
  "token": "tok_9f3a7c21b8e4",
  "brand": "visa",
  "last4": "1111",
  "fingerprint": "fp_5d1c..."
}

3DS orchestration hooks

QGate treats authentication as a pluggable step. Before authorization, the gateway invokes the configured 3DS hook, passing the transaction context and receiving back an authentication result (frictionless, challenge required, or authentication attempted). The resulting authentication values — the CAVV/AAV and the ECI — are then attached to the authorization message. This design lets you satisfy scheme mandates and regional SCA requirements without QGate itself becoming an ACS.

// config/qgate.php — 3DS hook binding
return [
    'threeds' => [
        'driver'   => 'connector',        // or 'external'
        'endpoint' => 'https://3ds.internal/authenticate',
        'timeout'  => 8,
        'on_unavailable' => 'authorize_without', // or 'decline'
    ],
];

Editions

QGate is licensed in three editions. The edition is encoded in your license key and enforced at activation; upgrading is a re-entitlement, not a reinstall.

Standard — single acquirer connector, card acquiring, tokenization vault, capture/refund, and settlement import. Suited to a single business unit accepting cards.
Professional — multiple acquirer connectors, alternative payment methods, the 3DS orchestration hooks, and webhook fan-out. Suited to multi-method acceptance and moderate volume.
Enterprise — everything in Professional plus multi-tenant isolation, high-availability clustering of the authorization engine, HSM-backed vault keys, and advanced reconciliation. Pairs with QRoute for cross-acquirer orchestration.

Sizing by transaction volume

Size QGate by sustained authorizations per second (TPS) at peak, not by daily totals. As a starting point: up to ~50 TPS runs comfortably on a single application node (8 vCPU / 16 GB) plus a primary MariaDB instance. From ~50 to ~250 TPS, run two or more stateless authorization nodes behind a load balancer with a MariaDB primary and read replica. Above ~250 TPS, the Enterprise edition's clustered engine and a partitioned ledger are recommended, and the vault should be scaled independently. Always provision the ledger's storage for retention: transactions are never deleted, only archived.

Integrating via /api/v1

All QGate operations are available over the versioned REST surface at /api/v1. Requests are authenticated with per-application API keys and signed; webhooks are delivered with an HMAC signature you verify against the shared secret. A typical purchase flow is a token creation, an authorization referencing the token, and a later capture:

POST /api/v1/payments
{
  "amount": 4200,
  "currency": "USD",
  "source": "tok_9f3a7c21b8e4",
  "capture": false,
  "threeds": "required"
}

See the QRoute overview for orchestrating these authorizations across multiple acquirers, and the API integration guide for full endpoint, signing, and webhook details.