Skip to main content

Overview

Every deposit order comes with a hosted payment page. You don’t build any payment UI: redirect your customer to the paymentPageUrl from the create-order response, and C2C walks them through paying the assigned member. This works the same for orders accepted as Awaiting (no eligible member at creation): the page assigns a member at checkout.
C2C has no separate “initiate checkout” endpoint. Creating a deposit order is creating the checkout session: one call returns both the order and its paymentPageUrl.

The payment page URL

Redirect the customer as soon as you receive the URL. Don’t cache it, email it hours later, or reuse it for another order. If the link expires, the order ends Expired (or CancelledTimeout if no member was ever assigned) and you receive an order.failed webhook. Create a new order with a new Idempotency-Key; you can reuse the same merchantOrderRef.

What your customer sees

1

Open on your payment method

The page shows your merchant name, the amount and the C2C order reference, and opens directly on the walletType you requested (for example JazzCash QR). The customer doesn’t pick a method first. C2C reserves a receiving account of exactly that method, and the order moves to AwaitingCustomerPayment. If other methods are enabled for your account and available for the order, the customer can tap Change to pay with one of those instead.If the order is Awaiting, an online member is assigned at this point. If nobody with an account of that method is online yet, the page shows “Finding an available agent…” and re-checks automatically every 10 seconds until it can show where to pay or the link expires. The customer must not send money until an account number, Till ID or QR code is shown.
2

Pay and confirm

The customer sends exactly the order amount from their own wallet app and confirms on the page. What the page shows and what the customer submits depend on the method: see Account number and Till ID methods and QR methods. In both cases the order moves to AwaitingMemberConfirmation.Whatever the customer submits is their claim, not proof: the order completes only when the member confirms the money arrived.
3

Wait for verification

The page waits while the member verifies the payment, and updates by itself to a success or a cancelled/expired screen. If you set successUrl / failureUrl, it then sends the customer back to your site. If the customer reloads or reopens the link meanwhile, the page resumes here instead of asking them to confirm again.
If the assigned member goes offline before the customer opens the page, C2C can reassign the order to another available member at checkout. This is transparent to you: the orderId doesn’t change. If the customer pays with a different method than you requested, your fee is re-quoted for the method used.

Account number and Till ID methods

JazzCash, JazzCashTillID, Easypaisa and TillID. The page shows the provider, the receiving account number or Till ID with a copy button, the exact amount to send, numbered steps for that provider’s app and a How to Pay guide. The account holder’s name isn’t shown.
  1. The customer copies the account number or Till ID.
  2. They pay exactly the order amount in their JazzCash or Easypaisa app.
  3. They enter the last digits of the transaction ID (TID) of that payment. The order’s txnRefDigitsRequired sets how many digits (4 by default). The confirm button stays disabled until they have entered them.
They can also attach a screenshot of the payment (optional; JPEG, PNG or WebP up to 5 MB), which the member sees when verifying.

QR methods

JazzCashQR and EasypaisaQR. These methods never ask for a transaction ID, and txnRefDigitsRequired has no effect on them.
  1. The customer first submits the account they pay from. For JazzCash QR that is their JazzCash account number (03XXXXXXXXX); for Easypaisa QR it is the last 4 digits of their Easypaisa IBAN. The member uses it to find the incoming payment.
  2. Only then does the page show the member’s QR code, with a Save QR button. A button that opens the JazzCash or Easypaisa app is shown only when C2C has configured a verified app link for that provider.
  3. The customer scans the code in their JazzCash or Easypaisa app, or loads the saved image there, and pays exactly the order amount.
  4. They tap I’ve Completed Payment. They can attach an optional payment screenshot first, as above.
Until they tap I’ve Completed Payment, the customer can correct the account they entered. Afterwards it is final. The page remembers the submitted account in that browser (local storage, separately for JazzCash and Easypaisa) and prefills it on the customer’s next QR payment. Nothing is sent to C2C until the customer submits it, and they can clear it from the page.

Withdrawals

For a withdrawal the page works the other way round: the customer receives money, so it never shows an account to pay and never asks for a transaction ID.
1

Enter the receiving account

Only when you created the withdrawal without customerAccountNumber. The page is titled Receive Your Withdrawal and shows your merchant name, the amount and the order reference. The customer enters:
  • Wallet Account Number — checked against the order’s walletType (JazzCash / Easypaisa: an 11-digit mobile account number such as 03001234567; +92… is accepted and normalised)
  • Account Holder Name
The wallet provider is the order’s walletType and the amount is the order’s amount; the customer can change neither. They must submit before the link expires (15 minutes), otherwise the order ends CancelledTimeout.
2

Processing

After submitting — or immediately, when you sent the account yourself — the page shows that the withdrawal is being processed, with the wallet, the account (all but the last 4 digits hidden) and the account holder name. It updates by itself. Reloading the page returns here; the submitted account cannot be edited, and submitting the same details again has no effect.
3

Outcome

When the member has sent the payout the page shows Withdrawal sent. If the withdrawal is rejected, cancelled or expires it shows that no payment was sent. If you set successUrl / failureUrl, the customer is then returned to your site.
An account entered on the page is exactly as authoritative as one you send in customerAccountNumber: the member pays that account. Send the customer to the page only from a session you trust to be theirs.

Returning the customer to your site

Set successUrl and failureUrl when you create the deposit or withdrawal. When the order reaches a final status while the customer still has the page open, the page shows the result, then sends the customer back to you after 5 seconds. A “Return now” link lets them go back straight away. C2C appends the outcome to the URL, keeping your existing query parameters:
These parameters come through the customer’s browser and can be edited. Use c2c_order_id only to know which order to show. Before fulfilling, confirm the status from your backend with a webhook or a status query.
Both URLs must be absolute http:// or https:// URLs. Any other scheme, such as javascript:, is rejected with 400 when the order is created. The redirect only happens if the customer keeps the page open until the order is final. A member can take a while to confirm, so also give customers a way back of their own: for example a “Check my order” page on your site, or open paymentPageUrl in a new tab while your page polls your backend.

Integration example

Node.js (Express)

Security notes

  • The page and its backend endpoints are operated by C2C. Your API key and secrets are never involved, and the customer never sees them.
  • The page never asks for the customer’s wallet PIN or OTP. Customers pay from their own wallet app.
  • A payment screenshot is stored by C2C and shown only to the member assigned to the order and to C2C operations. It has no public link.
  • On the QR methods, the account the customer says they pay from is stored with the order for the member who verifies the payment. It isn’t returned by the Merchant API or sent in webhooks.
  • On a withdrawal the page never shows a member’s account, and shows the customer’s own account masked after it was submitted.
  • Never build or modify payment page URLs yourself. Always use the paymentPageUrl returned by the API.