QCard — Card Issuing

QCard — Card Issuing

QCard is the QoinPay Enterprise module for issuing and managing payment cards on infrastructure you control. It supports both physical and virtual cards across the complete issuing lifecycle — from BIN and product configuration, through cardholder enrolment and activation, to spend controls, replacement, and closure. Because QCard runs on-premise against your own MariaDB cluster, primary account numbers (PANs) and sensitive authentication data never leave your data centre, which materially simplifies your PCI DSS scope relative to a hosted issuer-processor.

Deployment architecture: your infrastructure plus the QoinPay license server
Deployment architecture: your infrastructure plus the QoinPay license server

Capabilities

QCard organises issuing around three durable objects: the card product (a template tied to a BIN range, scheme, currency, and default control profile), the card (an individual instance in a defined state), and the cardholder (the natural or legal person a card is bound to). A single product can back thousands of cards, and one cardholder can hold several cards across products.

Core capabilities include:

  • Physical and virtual issuance. Virtual cards are generated instantly for e-commerce or single-use scenarios; physical cards are produced through a personalisation file exported to your bureau in the scheme-mandated format.
  • Card lifecycle management. Every card moves through a governed state machine: requested → personalised → inactive → active → (suspended) → (expired|closed). Transitions are permission-gated and fully audited.
  • Spend and usage controls. Per-card and per-product limits cover transaction amount, daily and monthly velocity, merchant category (MCC) allow/deny lists, geographic restrictions, and channel toggles (ATM, POS, e-commerce, contactless).
  • PIN and 3-D Secure management. PIN set/reset and OTP-based cardholder verification are handled through the module without exposing clear-text values to operators.
  • Tokenisation hooks. QCard exposes the card reference needed to provision network tokens for wallet enrolment.

Key modules

  • Product Manager — defines BIN mappings, embossing templates, fee schedules, and default control profiles.
  • Card Operations — the day-to-day console for search, activation, suspension, replacement, and re-issue.
  • Controls Engine — evaluates authorisation requests against the active control set in real time and returns approve/decline decisions.
  • Cardholder Directory — KYC status, contact data, and card relationships, with configurable data-retention rules.
  • Personalisation Export — generates and encrypts bureau files for physical card production.

API and integration

QCard is driven through the shared /api/v1 REST surface. Cards are created, fetched, and transitioned with standard resource calls, and authorisation-time events are delivered to your systems through signed webhooks so your ledger and fraud systems stay in step.

POST /api/v1/cards
Content-Type: application/json
Authorization: Bearer {token}

{
  "product_code": "VIRT-NGN-01",
  "cardholder_id": "chd_8fa21c",
  "form_factor": "virtual",
  "controls": {
    "monthly_limit": 500000,
    "allowed_channels": ["ecommerce"]
  }
}

Webhook deliveries are signed; verify the signature header against your issued secret before trusting the payload. See the API overview for signature construction and retry semantics.

API integration: your system and the QoinPay /api/v1 REST and signed webhooks
API integration: your system and the QoinPay /api/v1 REST and signed webhooks

Editions

QCard is offered in three editions:

  • Standard — virtual issuance, core lifecycle, and product-level controls. Suitable for closed-loop and single-programme issuers.
  • Professional — adds physical personalisation export, per-card controls, PIN management, and the full webhook event set.
  • Enterprise — adds multi-BIN and multi-entity segregation, tokenisation hooks, dual-control on high-risk operations, and extended audit retention.

Edition is recorded in your entitlement and enforced by the license key; upgrading an edition is an entitlement change rather than a reinstallation.

Sizing metric — active cards

QCard is licensed by active-card count, measured as the peak number of cards in a billable state (active or suspended) during a licensing period. Cards that are closed or expired do not count, nor do virtual cards that were issued and never activated. The license key encodes a tier ceiling; when your active-card population approaches the ceiling the administration console raises a warning, and issuance is blocked once the ceiling is exceeded until the entitlement is expanded. Size to your projected peak rather than your day-one figure, since re-issues and replacements briefly hold two active records.

Licensing and Software Subscription & Support

QCard is perpetually licensed: the right to run the software does not expire. The first year of Software Subscription & Support (S&S) is included with the initial order and covers scheme-mandate updates, security patches, and support. Scheme compliance changes are frequent, so keeping S&S current is strongly advised for any production card programme.

Software Subscription and Support timeline: year one included, renewal, lapse
Software Subscription and Support timeline: year one included, renewal, lapse

Deployment

QCard installs alongside the other QoinPay modules on your application tier and shares the central MariaDB instance and the license activation flow. It requires an HSM or KMS-backed key store for PAN encryption and PIN block handling; the installation guide covers the supported key providers. For related concepts, see the Getting Started, Licensing, and API overviews.