📘
PCI Note: This operation requires you to collect and transmit PAN/CVV server-side. Do not use from browsers or mobile apps. Prefer the Hosted Checkout flow where possible.

Endpoint

POST https://secure.3gdirectpay.com/API/v6/

Headers

Content-Type: application/xml; charset=utf-8
Accept: application/xml

Request

Required Fields

Field	Required	Description
`CompanyToken`	Yes	Your merchant token
`Request`	Yes	Must be `chargeTokenCreditCard`
`TransactionToken`	Yes	Token returned by `createToken`
`CreditCardNumber`	Yes	Primary Account Number (PAN) — no spaces
`CreditCardExpiry`	Yes	`MMYY` (e.g., `1227`)
`CreditCardCVV`	Yes	3–4 digits
`CardHolderName`	Yes	Name as printed on card
`ChargeType`	Optional	If supported (e.g., `Auth`, `Sale`) — optional/tenant-specific
`ThreeD`	Optional	3-D Secure data object if you perform 3DS off-gateway

If your tenant enforces 3-D Secure, provide ThreeD fields (see example). Otherwise omit the object.

Example — Basic Card Charge (XML)

<?xml version="1.0" encoding="utf-8"?>
<API3G>
  <CompanyToken>YOUR_COMPANY_TOKEN</CompanyToken>
  <Request>chargeTokenCreditCard</Request>
  <TransactionToken>72983CAC-5DB1-4C7F-BD88-352066B71592</TransactionToken>

  <CreditCardNumber>4111111111111111</CreditCardNumber>
  <CreditCardExpiry>1227</CreditCardExpiry>
  <CreditCardCVV>123</CreditCardCVV>
  <CardHolderName>ALex Nkosi</CardHolderName>
</API3G>

Example — With 3-D Secure Data (XML)

Field names vary by setup. The common pattern below is widely used; confirm with your DPO contact if your tenant expects different tags.

<?xml version="1.0" encoding="utf-8"?>
<API3G>
  <CompanyToken>YOUR_COMPANY_TOKEN</CompanyToken>
  <Request>chargeTokenCreditCard</Request>
  <TransactionToken>72983CAC-5DB1-4C7F-BD88-352066B71592</TransactionToken>

  <CreditCardNumber>4111111111111111</CreditCardNumber>
  <CreditCardExpiry>1227</CreditCardExpiry>
  <CreditCardCVV>123</CreditCardCVV>
  <CardHolderName>Alex Nkosi</CardHolderName>

  <ThreeD>
    <ECI>05</ECI>
    <CAVV>AAABBIc…base64…</CAVV>
    <XID>MmY5…base64…</XID>
    <Version>2.1.0</Version>
  </ThreeD>
</API3G>

Response

Success

<?xml version="1.0" encoding="utf-8"?>
<API3G>
  <Result>000</Result>
  <ResultExplanation>Transaction charged</ResultExplanation>
  <!-- Some tenants may also include TransRef / Approval / AuthCode -->
</API3G>

Errors (examples)

<API3G>
  <Result>200</Result>
  <ResultExplanation>Transaction already paid</ResultExplanation>
</API3G>

<API3G>
  <Result>804</Result>
  <ResultExplanation>Error in XML</ResultExplanation>
</API3G>

<API3G>
  <Result>902</Result>
  <ResultExplanation>Data mismatch in one of the fields: CreditCardExpiry</ResultExplanation>
</API3G>

<API3G>
  <Result>950</Result>
  <ResultExplanation>Request missing mandatory fields: CreditCardNumber</ResultExplanation>
</API3G>

▶️ Test in Postman

Common codes

Code	Meaning
`000`	Transaction charged (success)
`200`	Transaction already paid
`801`	Missing `CompanyToken`
`802`	`CompanyToken` does not exist
`803`	Invalid request name
`804`	XML error
`902`	Data mismatch (field-specific)
`903`	Transaction not found
`905`	Transaction already charged
`950`	Missing mandatory field(s)

For gateway/verify semantics after the charge, see Gateway Response Codes (v6) and Verify Token Response Codes (v6).

Flow (Direct Card Charge)

sequenceDiagram
  participant M as Merchant Server
  participant D as DPO API

  M->>D: createToken → TransactionToken
  M->>D: chargeTokenCreditCard (PAN+CVV+Expiry)
  D-->>M: Result (000/…) immediate outcome
  M->>D: (optional) verifyToken for reconciliation
  D-->>M: BackURL (if configured) with final status

Security & Compliance

Server-side only. Never send PAN/CVV from browser/mobile to your server unless you are fully PCI compliant.
Do not log CreditCardNumber or CreditCardCVV. Mask where unavoidable (last 4 only).
Prefer Hosted Checkout or tokenization flows where possible to reduce PCI scope.
If using 3DS off-gateway, transmit ECI/CAVV/XID/Version exactly as provided by your ACS/3DS server.

Implementation Tips

Validate MMYY format before sending.
If you see 200 Already paid or 905 Already charged, stop and reconcile (don’t re-charge).
Use your own idempotency guard on (TransactionToken, action=cardCharge) to prevent duplicates on retries.
For declines or uncertain states, follow up with Transaction Status Lookup and your BackURL webhook.