Overview

​

📄 Guide

This page gives you the full picture of the Corporate Card Open Platform: what it is, its core value, where it fits, the capability and card-type map, and the security and compliance boundary. By the end you can judge whether the product matches your business.

​

What it is

Issuing, made simple The Corporate Card Open Platform lets you embed card issuing directly into your own product and issue corporate cards that your business customers can use for online and offline payments worldwide — without applying for an issuing license, negotiating BIN sponsorship, building an issuing system, or integrating one by one with card networks, issuing banks and clearing institutions. DCS carries all of that underneath; you consume it through a single set of OpenAPIs. DCS does the heavy lifting in the background — onboarding due diligence, card production and issuance, authorization processing, clearing and ledgering, compliance and risk control. You focus on the product and experience you offer your business customers, and you remain their single point of contact throughout. Licenses, BINs, PCI, card production and transaction processing are all borne by DCS; you never have to invest in them separately. API first: your product plus our issuing infrastructure The Corporate Card Open Platform’s core deliverable is a set of OpenAPIs covering the full issuing life cycle — company onboarding, employee creation, card application, funding, spend controls, statements and reconciliation, and 3DS authentication. Every capability is reachable through an API call. API-native issuing means turning card issuing into a programmable, embeddable, automatable infrastructure component. You never deal with BINs, card networks or clearing rails directly; they are encapsulated behind the API and orchestrated by DCS.

• Issuing is no longer a redirect. In the traditional model your customer leaves your product, fills in forms on a bank portal, applies, waits for review, receives the card, activates it — a broken, fragmented journey. Through the API the whole flow lives inside your product: your customer clicks a button in your console and the card exists within ten seconds, without ever leaving your page.
• Data no longer has gaps. Authorizations, settlements, balance movements, statement generation — every key event is pushed to your system over webhooks, instead of a monthly PDF statement to reconcile by hand. The transaction data your customer sees, the data you see and the data DCS sees are the same data.
• Scaling needs no renegotiation. A new card type? Different limit rules? Another funding mode? If DCS’s capability set covers it, you get it at the API level — no new contract, no new negotiation, no repeat of the commercial process.

A three-tier model: you own the customer experience Your business is organized in a partner → company → employee structure:

• The partner is you — the platform embedding card issuing into its own product.
• A company is your business customer; companies register, onboard, fund and manage budgets.
• An employee is the end cardholder; spending happens in their hands.

Two card forms

• Virtual cards: usable the moment they are issued, delivered in seconds — suited to online payments, e-commerce purchasing and ad spend.
• Physical cards: obtained by upgrading an activated virtual card under the same number — PAN, CVV, expiry and card ID all stay unchanged, so no targets need migrating. Suited to offline travel, dining and procurement.

​

Core value

Self-service issuing over APIs, end to end From company onboarding and employee creation to issuing, funding, spending and settlement, the entire flow is exposed through one set of OpenAPIs and can be fully embedded into your systems for self-service operation, with no manual steps or offline processes. Time-consuming stages — onboarding, employee creation, issuing — follow a synchronous-acceptance-plus-asynchronous-callback pattern: the endpoint returns an application ID immediately, the final result arrives through event callbacks, and polling is always available as a fallback. Every write endpoint supports an idempotency key, so cardNetwork retries and duplicate submissions are safe. Two funding modes, granularity of your choice Under one business customer you can combine two funding modes freely: a company funding pool (balance shared across cards, centralised bookkeeping — good for unified control) and per-card dedicated balances (earmarked funds with independent caps — good for budget isolation). Both share the same endpoints and support two-way transfers — allocate budget down to a card, or sweep a card’s balance back to the pool — all closed-loop within the same currency and the same company. You arrange them around your customer’s organization and budgeting habits, rather than bending to a fixed product shape. Event-driven across the chain, traceable and reconcilable Onboarding, issuing, authorization, settlement, deposits and balance movements are all pushed over webhooks, so your system tracks business progress in real time and drives its own flows. Every event carries a globally unique ID for idempotency, is signed with HMAC-SHA256 against tampering, and is retried automatically on delivery failure; every event class also has a matching query endpoint as a fallback, so nothing depends on a single channel and the books stay traceable and verifiable throughout.

​

Where it fits

The value of a corporate card is turning “who can spend, how much, and on what” into programmable rules. These are the most common partner scenarios, all achievable on the same set of endpoints: Every scenario shares the same endpoints and the same company entity; the card type is decided solely by the type code at application time, and one employee can hold pool-funded and dedicated-balance cards at the same time. Spend controls (amount / count / currency / MCC / region) are implemented through velocity rules — see Limits and statements and the API reference. Control granularity is yours to define Spend control is implemented through velocity rules — per-transaction and daily / monthly / quarterly / yearly caps on amount and count, plus allow/deny lists for currency, MCC and transaction region. Rules bind to cards or employees. When an object has several rules bound, the system automatically applies the strictest value on each dimension. That lets you satisfy company-wide control and department-level refinement at the same time, without building a rule-inheritance hierarchy.

​

Capability map

Company onboarding Employee management Card management Fund management

​

Card types

A card type is the combination of two orthogonal dimensions: the holder (who the card is issued to) and the balance mode (which account pays). You specify it with a card type code at application time.

• Custodian: regulation requires every company card to name an active employee of that company as its custodian. The custodian is contacted when something is wrong with the card, and completes verification when a purchase triggers a 3DS challenge.
• Embossed name: two embossed lines are supported and can be specified when applying for the physical card.
• Availability: which card types can be opened, and how many, is configured by DCS per partner and per company.
• Virtual first: the issuing endpoint creates a virtual card that is usable immediately. If a physical card is needed, upgrade the activated virtual card in place — the same card, the same number.

​

Security and compliance

Compliance and security are the entry ticket to card issuing, and DCS carries the heaviest parts for you: licensing and BIN ownership, the PCI data environment, KYB/KYC due diligence, risk control and sanctions screening. On top of that, you integrate against the following mechanisms.

• Due diligence: KYB for company onboarding, KYC for employees. After a rejection of either kind, correct the key fields and resubmit under the same application.
• Risk control and freezing: freezes come from two sources — partner-initiated freezes can be lifted self-service over the API; risk / regulatory / judicial freezes cannot, and go through support. Two granularities — freezing a card stops only that card, freezing an employee makes every card under them decline. Five capability-domain freeze codes are available (account / cash-in / cash-out / payment / card), each added or removed independently.
• Data security: each partner receives an AK / SK pair. The SK never appears in any request in clear text; it is used only to compute the HMAC-SHA256 signature locally, and requests carry a timestamp and nonce against replay. Your identity is established by the gateway from the AK signature check; any institution identifier carried in the request body is ignored.
• Card data protection: regular query endpoints never return the full PAN — only the first 6 digits (BIN) and the last 4. The full PAN / CVV2 / expiry are returned only by the secure card endpoint, AES-GCM encrypted, and only to allowlisted PCI DSS-certified partners; partners without PCI DSS can integrate our hosted secure card page.

​

Next steps

• What to prepare before integrating: First steps
• Run the onboarding → funding → issuing → spending loop on the shortest path: Quickstart
• Understand holders, funding and state machines: Holders and the funding model