Authorization Forwarding Model

​

📄 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.

​

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: 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 for details): 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 and Authorization and authorization forwarding notifications.

​

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 to see how the enterprise security deposit relates to the T+1 settlement payout, then work through Authorization and authorization forwarding notifications to implement receiving, decrypting, deciding and responding on authUrl.