Skip to main content

​
📄 Guide

Whether you are an exchange, a wallet or a platform, Partner-Managed mode keeps every cardholder’s spending limit in your hands and leaves every authorization decision to you, while DCS turns those decisions into real money at the card network. This page explains the two ideas that make the fund model click: the two-leg liability (an authorization hold and a settlement debit are two separate events) and the payout rhythm (DCS pays the card network on T+1, you replenish the security deposit on T+X). Once these two are clear, you can model your own ledger correctly: no double-holding of user funds, and no security deposit drained before settlement lands.

​
Two pools of money: user wallets vs the enterprise security deposit

Partner-Managed mode involves two distinct pools of money. Always keep them apart:
Key point: user limit rules are maintained by the partner, and whether any single authorization passes is decided by the partner against its own limit rules (this is exactly what authorization forwarding means, see Authorization Forwarding Model). After the partner approves, DCS checks that your enterprise security deposit is sufficient: if availableAmount falls short, the authorization is declined.
Real-time figures for the security deposit come from the enterprise balance endpoint, which returns three amount fields:
Endpoint: GET /open-api/enterprise/v2/enterprise-balance (queried by cardProfileId). Line-level records are available from GET /open-api/enterprise/v1/enterprise-balance-record.

​
Fund model 1: the two-leg liability, an authorization hold then a settlement debit

In funding terms a card purchase is not a single deduction but two events that happen in sequence. This is the fundamental difference from “a wallet debiting the balance directly”.
The two-leg liability: authorization hold then settlement debitThe two-leg liability: authorization hold then settlement debit
  • Leg one, authorization: when the cardholder pays, the card network sends an authorization request in real time. DCS forwards it to the partner, who decides whether to approve it against its own user limit rules. On approval the partner places a hold on the matching limit, and DCS reserves the same amount against availableAmount in the security deposit. At this point no money has actually moved.
  • Leg two, settlement: the merchant later presents the transaction for settlement (usually from T+1 onwards, sometimes later); only once DCS receives it does the actual debit happen, and the hold from leg one is released.
The authorized amount and the settled amount need not match: a merchant may settle for less (a restaurant dropping the pre-authorized tip), for more (fuel stations, hotels), in several instalments, or settle with no prior authorization at all (offline transactions). DCS uses Outstanding (the unsettled balance) as the intermediate ledger that ties the two legs together, so holds and debits always reconcile back to zero. Common combinations (all 13 scenarios are covered in Authorization and Settlement Scenarios):
Practical reminder for partners: place the hold on the user wallet when you respond to the authorization forwarding notification (authUrl), and only debit and release the hold once the settlement appears in the daily transaction reconciliation file. Never debit the balance at authorization time, or reversals, under-settlements and expiry releases will leave your books out of step with reality. The data structures for authorizations and transactions are documented in the Authorization Data Dictionary and the Transaction Data Dictionary.

​
Fund model 2: the payout rhythm, DCS pays the card network on T+1, the partner replenishes on T+X

The second fund model is about timing. Authorization is real time, actual funds settle later, and DCS’s payout obligation to the card network is non-negotiable:
The payout and replenishment rhythmThe payout and replenishment rhythm
  • DCS to the card network: T+1 payout. Whatever time the settled funds actually arrive from the cardholder side, DCS must front the payout on the card network’s schedule (usually T+1). The money for that advance is your prefunded enterprise security deposit.
  • Partner to DCS: T+X replenishment. Once the deposit has been consumed you need to prefund promptly, bringing availableAmount back to a safe level. The exact replenishment cycle and method follow your contract.
Hard risk limit: once availableAmount in the security deposit is no longer sufficient, DCS declines subsequent authorizations, even if the user wallet still has a balance. Set an alert threshold on availableAmount, poll it regularly, and schedule replenishment ahead of time. Push-based alerting and webhooks are on the roadmap; for now, monitor the level by polling the enterprise balance endpoint.

​
Next steps

With the fund model settled, head to the Transaction Lifecycle to follow one transaction end to end from authorization to settlement. For reconciliation files, see Daily Reconciliation Reports.