> ## 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.
# Authorization Forwarding Model
> The core idea behind Partner-Managed: the partner owns the spending limits, and the partner makes a real-time decision on every authorization.
## 📄 Guide
Whether you are an exchange, a wallet or a platform, Partner-Managed lets you **own the available limit of every cardholder and approve or decline every purchase in real time**. DCS issues the cards, forwards each network authorization request to you securely, and completes settlement and reconciliation once you approve, while **the limit rules and the risk logic stay with the partner at all times**.
As a licensed issuer with its own BIN, DCS ships this "the authorization decision goes back to you" capability as ready-to-use infrastructure, so you need neither an issuing license of your own nor a direct card network connection.
## The model in one sentence
> **The partner owns the limits; the partner makes the authorization decision.**
* **Limit rules and the authorization decision belong to the partner.** How much each cardholder may spend, who approves it and whether it goes through are defined and decided by the partner under its own limit rules. DCS acts on that decision and records the fund hold and the settlement entry as it forwards and settles, so both sides reconcile to the same numbers.
* **DCS holds the enterprise security deposit you have paid in.** It backs the T+1 settlement to the card network and is independent of the limit decision on any single authorization.
* **On every purchase, DCS hands the decision to you.** When a cardholder pays, DCS sends one notification for that authorization to the partner `authUrl`, and the partner replies with approve or decline.
This is the fundamental difference from DeCard-Managed. Under DeCard-Managed, DCS applies the limit rules and makes the authorization decision on your behalf. Under Partner-Managed, **both the limit rules and the decision on every single authorization return to the partner**, and DCS takes care of secure forwarding, settlement and backing the settlement payout.
## What happens when a purchase is authorized
The diagram below traces an ordinary purchase (`direction=OUTGOING`) end to end under Partner-Managed:
Key points:
* **The decision sits with the partner**: steps 3 to 5 of the diagram happen entirely inside the partner. Whether to let a transaction through, and under which rules (limits, per-transaction caps, merchant and MCC blocklists and so on), is yours to define; DCS neither participates in those rules nor stores them.
* **DCS is the secure transport**: DCS encrypts the authorization request and forwards it to you, encrypts your decision back towards the card network, and guarantees that both messages are authentic (see the encryption section below).
* **The security deposit is a company-level advance of funds**: what DCS holds is the partner enterprise security deposit, which lets DCS settle to the card network on time on T+1. It is a company-level settlement guarantee, independent of the limit decision on any single authorization. For how the money moves, see [Fund model](./fund-model).
## How the authorization decision gets back to DCS
Once the notification reaches your `authUrl`, the partner applies its business rules and returns a `responseCode`. The permitted values come from the [authorization forwarding notification payload](../how-to-use/transactions/authorization):
| responseCode | Meaning |
| ------------ | -------------------------------- |
| `"00"` | Approve |
| `"01"` | Decline, insufficient funds |
| `"11"` | Decline, transaction not allowed |
| `"21"` | Decline, no response |
return a specific `responseCode` when you decline, so that both sides can tell decline reasons apart during reconciliation.
The mapping from the real-time reply to the stored record is fixed: `responseCode=00` is persisted as `approveFlag=A`, while `01`, `11`, `21` and any other non-`00` result are persisted as `approveFlag=D`. `responseCode` is used in the partner's synchronous response; `approveFlag` appears in the authorization result webhook and the daily authorization report.
## Not every authorization comes from a live card payment
Besides live purchases, authorization records also cover system back-fills and releases. The `authType` field appears both in the forwarding notification and in the daily authorization report (see [authorization enumerations](../how-to-use/transactions/authorization) for details):
| authType | Name | Description |
| --------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `NORMAL` | Normal authorization | Created from a real-time authorization callback on the channel; covers purchases, incremental authorizations, reversals, refunds, withdrawals, balance enquiries and other live scenarios |
| `FORCE_AUTH` | Forced authorization | Backfilled by the system: settlement arrives with no matching authorization (an offline transaction, for example), or the settled amount differs from the held amount and the difference has to be booked |
| `EXPIRED_RELEASE` | Expiry release | The authorization was never settled in time, and the channel uses the settlement file to instruct release of the funds it had held |
| `STATUS_DIFF_RELEASE` | Status mismatch release | Reconciliation correction for the case where the channel declined the authorization on timeout while DCS had already approved it |
When you maintain cardholder limits in your own ledger, account for all four types. For example, an `EXPIRED_RELEASE` should release the limit you held earlier.
## Security prerequisites for authorization forwarding
Handing the authorization decision to the partner only works if the forwarding channel is trusted in both directions. DCS uses **RSA-2048 with SHA256withRSA for two-way signing and encryption**, with no additional AES/IV layer:
* **DCS to partner**: the core authorization fields are encrypted with **the partner RSA public key** and signed with **the DCS RSA private key**. The ciphertext goes into `data.encryptedData` in the request body, and the signature into the `X-Auth-Signature` request header.
* **Partner to DCS**: the response is encrypted with **the DCS RSA public key** and signed with **the partner RSA private key**, carried in the response body as `encryptData` and `signature`.
On the request side, `data.encryptedData` is the single ciphertext of all 15 serialized authorization business fields (authorization, user, card, amount, merchant and MCC, transaction type and so on). It is not limited to `authId`, `direction`, `currency` and `amount`.
Prerequisites before you integrate:
* An Enterprise is live, with `authUrl` (the authorization notification endpoint) and `externalPublicKey` (the partner RSA public key) configured. **Who does what: the partner** configures, **DCS** registers
* The IP whitelist for authorization forwarding notifications is in place. **Who does what: the partner** supplies the addresses, **DCS** allows them
* At least one card has been issued successfully
> For encryption details, key generation with openssl, obtaining the production public key and configuring the IP whitelist, see [Authentication and security](../integration-resources/authentication) and [Authorization and authorization forwarding notifications](../how-to-use/transactions/authorization).
## Who this model is for
* Exchanges, wallets and platforms that already run their own user system and limit or risk logic and want to **keep the authorization decision**
* Partners that prefer one enterprise security deposit to back settlement while they themselves control each cardholder limit and each authorization decision
* Teams that want licensed issuing at minimal cost and are happy to leave card network connectivity and settlement to DCS
## Next steps
With "you own the limits, you own the authorizations" clear, start with [Fund model](./fund-model) to see how the enterprise security deposit relates to the T+1 settlement payout, then work through [Authorization and authorization forwarding notifications](../how-to-use/transactions/authorization) to implement receiving, decrypting, deciding and responding on `authUrl`.