Overview
A deposit collects money from your customer. The customer pays a verified C2C member from their own mobile wallet, the member confirms receipt, and C2C credits your merchant wallet with the amount minus fees. ThewalletType you request is the payment method: JazzCash or Easypaisa, by account number, Till ID or QR code. The customer is only ever given a receiving account of exactly that method.
Flow diagram
Step by step
1. Create the order
Your backend calls Create Deposit Order with a signed request and anIdempotency-Key. Before creating anything, C2C checks:
- API key valid and active, otherwise
401 - Signature (the body’s
signaturefield) valid, otherwise401. Deposits are always signature-enforced. - Request valid, otherwise
400 - Merchant account active and IP whitelist passed, otherwise
403 - Payment method (
walletType) enabled for deposits on your account, otherwise422 merchantOrderRefnot already used by an order that is in progress or completed, otherwise409. SeemerchantOrderRefrules.
JazzCash is never given a JazzCash Till ID or QR code, and never an Easypaisa account. See Exact matching.
- Member found: the order is created as
Queued(stageAssigned) with the member already assigned, and the member is notified in their app. - No member right now: the order is still accepted (
200) asAwaiting(stageAwaiting), with the usualorderId,orderReferenceandpaymentPageUrl. A member is assigned when the customer opens the payment page.
2. Redirect the customer
Send the customer topaymentPageUrl right away. The link is valid for 15 minutes. See Hosted payment page.
3. Customer pays
The page opens on the method you requested. The customer sees where to pay, sends the money from their wallet app, and confirms on the page. What they submit depends on the method:
The order moves
Queued (or Awaiting) → AwaitingCustomerPayment → AwaitingMemberConfirmation. See Hosted payment page for each screen.
For an Awaiting order, an online member with an account of the requested method is assigned as soon as the customer opens the page, and their account is shown. If none is online yet, the page shows “Finding an available agent…” and re-checks automatically every 10 seconds. The customer must not send money until an account number, Till ID or QR code is shown.
4. Member confirms
The member checks that the payment arrived:- Confirmed →
Completed. Your wallet is credited amount − fee, and anorder.completedwebhook is sent. - Rejected, for example because no matching payment was found →
Rejected, and anorder.failedwebhook is sent.
5. Fulfil
Fulfil the purchase only when the status isCompleted. If you set successUrl / failureUrl, the payment page sends the customer back to you with the outcome appended; still confirm the status server-side before fulfilling. See Returning the customer.
Status lifecycle
Example: complete deposit integration
Best practices
- Store
orderIdand yourIdempotency-Keywith your order before you redirect. - Use webhooks and reconcile: every final outcome sends a webhook, but
ManualReviewdoesn’t until it’s resolved, and deliveries can fail. - Don’t fulfil early:
Awaiting,Queued,AwaitingCustomerPaymentandAwaitingMemberConfirmationare all in-progress states. - Redirect
Awaitingorders as usual. The payment page assigns a member when the customer opens it. - Treat
ManualReviewas pending. The customer may have paid, so don’t ask them to pay again until C2C resolves it. - One live order per
merchantOrderRef. To let the customer try again after a failed order, create a new order (newIdempotency-Key); you can reuse the samemerchantOrderRef.