> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> What the Corporate Card Open Platform is: embed card issuing into your product and issue globally accepted corporate cards to your business customers — the three-tier identity model, two funding modes, four card types and the security and compliance boundary.
## 📄 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:
| Scenario | Description | Recommended card type |
| -------------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------- |
| Online marketplaces / e-commerce | Pay platforms and marketplaces with per-transaction control over virtual cards | Company utility card / employee card (company pool) |
| Online advertising | Isolate ad-platform spend with periodic caps | Dedicated-purpose card (own balance, capped) |
| SaaS and cloud services | Recurring subscription renewals, locked by category | Company utility card or dedicated-purpose card |
| Business travel and dining | Hotels, flights and dining offline | Employee card (company pool / own balance) |
| Supplier and goods payments | One card per supplier or project, each with its own balance | Dedicated-purpose card |
| Everyday employee expenses | An expense card with its own limits per employee | Employee card |
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](../basic-concepts/limits-and-billing) 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**
| Capability | Description |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Company onboarding | KYB due diligence first; on approval the company is created with its funding pool |
| Query onboarding application | Application status, KYB result and rejection reason |
| Resubmit for review | After a KYB rejection, correct the legal name / registration number and resubmit under the same application |
| Query company detail | Company name, registration number, pool currencies, status and more |
| Status update (freeze / unfreeze) | Add or remove behavioral states per capability domain — set semantics, idempotent |
| Low-balance alert | Threshold and notification mailbox per currency; crossing the threshold triggers a webhook and an email |
**Employee management**
| Capability | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------- |
| Create employee | Accepted asynchronously; the employee ID is issued once KYC name screening passes |
| Query / resubmit | Query applications and results; after a KYC rejection, correct the information and resubmit |
| Update employee information | Name / phone / email changed one field at a time; a change re-triggers KYC review |
| Status update (freeze / unfreeze) | Freezing an employee makes every card under that employee decline transactions |
**Card management**
| Capability | Description |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Apply for a virtual card | Specify the holder and card type; risk checks and card creation run asynchronously, with the final state delivered by event callback |
| Query card / card list | First 6 and last 4 digits, company, holder, card type, cardNetwork, balance mode, currency, status |
| Open a receiving account for a dedicated-balance card | A dedicated-balance card can open a bank virtual account (VA) for inbound funds, or be funded from the company pool |
| Retrieve secure card details | Returns PAN / CVV2 / expiry as ciphertext for display in your own frontend; available only to PCI DSS-certified partners |
| Virtual-to-physical upgrade | Produce a physical card for an activated virtual card (same-number upgrade) |
**Fund management**
| Capability | Description |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Query balances | Available balance and in-flight holds by funding owner (company pool / dedicated-balance card) and currency |
| Get deposit details | Receiving account number, bank code / name, account name, SWIFT and so on, for the customer's bank transfer |
| Fund transfers | Internal transfers between company pool and dedicated-balance cards — same currency, same company, closed loop, with idempotency checks |
| Query transfer results / deposit records | Transfer status by identifier; paginated deposit history for reconciliation |
## 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.
| Business card type | Type code | Holder | Balance mode | Custodian | Typical use |
| ---------------------------- | -------------------------------- | -------- | ----------------------- | --------- | -------------------------------------------------------------------------------- |
| Company utility card | `COMPANY_UTILITY_CARD` | Company | SHARED (company pool) | Required | Unified company spend, many cards sharing one funding entry |
| Dedicated-purpose card | `COMPANY_DEDICATED_PURPOSE_CARD` | Company | DEDICATED (own balance) | Required | A dedicated budget per card |
| Employee card (company pool) | `EMPLOYEE_CARD_CORPORATE_FUNDED` | Employee | SHARED (company pool) | — | The most common expense card: the employee spends, the pool pays |
| Employee card (own balance) | `EMPLOYEE_CARD_SELF_FUNDED` | Employee | DEDICATED (own balance) | — | Travel or ring-fenced allowance cards — spending stops when the balance runs out |
* **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](./first-steps)
* Run the onboarding → funding → issuing → spending loop on the shortest path: [Quickstart](./quickstart)
* Understand holders, funding and state machines: [Holders and the funding model](../basic-concepts/identity-and-funding)