GetScratchCardForBank

Issues a scratch card server-to-server, signed by your backend. Because your backend validates the underlying order or payment before calling, this is the recommended issuance path.

Available

POST /api/GetScratchCardForBank

Environment	URL
Production	`https://bankapi.cheggout.com/api/GetScratchCardForBank`
UAT	`https://bankapi-uat.cheggout.com/api/GetScratchCardForBank`

Authentication — Signed envelope, the same mechanism as the session API

Prefer this over the client-side call

The mobile SDKs also expose a client-side scratch-card call. That path is convenient, but the request originates from a device rather than from a system that can prove a payment happened.

This endpoint keeps issuance behind your backend, so a card is only requested after you have verified the order — which is what you want when the card carries real value. See SDK integration.

Request

Standard signed envelope — CHANNELID, SIGN, BDATA.

Your channel is taken from CHANNELID in the envelope.

BDATA payload

Field	Type	Description
`virtualId`	string	The user's pseudonymous identifier
`transDateAndTime`	string	Transaction timestamp, `YYYY-MM-DD HH:mm:ss`
`amount`	string	Transaction amount. TBD The unit is not documented — see the caution below.
`mcc`	string	Merchant category code
`extTransactionId`	string	Your unique reference for this issuance
`campaignId`	string	The campaign for this event. This endpoint takes a campaign identifier, not a trigger code — see Trigger events.
`deviceToken`	string	Push token, for reward notifications

Confirm the amount unit before going live

Cheggout's material does not state whether amount on this endpoint is expressed in rupees or in paisa. Sending the wrong unit silently changes which campaign tier a transaction qualifies for, and it will not surface as an error. Confirm the unit with Cheggout during onboarding.

Payload before encoding (synthetic)
{
  "virtualId": "pub_8f14e45fceea167a",
  "transDateAndTime": "2026-07-31 14:15:31",
  "amount": "499.00",
  "mcc": "5699",
  "extTransactionId": "PUB_TXN_20260731_000117",
  "campaignId": "YOURCHANNEL_CAMPAIGN",
  "deviceToken": "REPLACE_WITH_DEVICE_TOKEN"
}

Never log or share a real device token

deviceToken is a push credential for a specific device. Keep it out of logs and support tickets, and never reproduce a real one in documentation or test fixtures.

The timestamp format differs here

This endpoint documents YYYY-MM-DD HH:mm:ss, while the Rewards Center GetReward documents DDMMYYYYHHMMSS. Use each endpoint's own format.

Example

curl -X POST https://bankapi-uat.cheggout.com/api/GetScratchCardForBank \
  -H "Content-Type: application/json" \
  -d '{
        "CHANNELID": "YOURCHANNEL",
        "SIGN": "REPLACE_WITH_YOUR_BASE64_SIGNATURE",
        "BDATA": "REPLACE_WITH_BASE64_PAYLOAD"
      }'

Response

Signed envelope — CHANNELID, SIGN, BDATA. Decode BDATA for the result.

Decoded BDATA — card issued

Field	Type	Description
`status`	boolean	`true` when a card was issued
`message`	string	`"success"`
`deepLink`	string	Opens the card inside the Cheggout SDK
`banner`	string	Banner image URL to show the user

{
  "status": true,
  "message": "success",
  "deepLink": "https://click.cheggout.com?type=reward&scratchCardId=1",
  "banner": "https://assets.example.com/reward-banner.png"
}

Decoded BDATA — no card

{
  "status": false,
  "message": "failure",
  "deepLink": "",
  "banner": ""
}

A false status is a normal outcome

It means the user was not eligible for this transaction — frequency caps, targeting, or an inactive campaign. Show nothing and continue. Do not retry or alert.

Failure responses may arrive unsigned

The failure form may be returned as a bare, unsigned body rather than inside a signed envelope. Your client must handle both shapes without throwing during signature verification. See API conventions.

Using the response

The deepLink and banner are what you surface to the user.

Pass the deepLink to the SDK in the launch payload's DeeplinkInfo field so the SDK opens directly on the card. See Android launch and iOS launch.

Your transaction reference

extTransactionId is your unique reference for this issuance. Use your real transaction reference so the card can be reconciled against the payment that earned it.

TBD Replay semantics for this endpoint are not documented. It is not stated whether resending the same extTransactionId returns the original card or issues a new one. Idempotency is documented only for GetReward and fetchCouponCode. Confirm the behaviour with Cheggout before you build retry logic on top of it.

Errors

Response	Meaning
`{"STATUS":"FAILURE","ERRORSTRING":"Signature Mismatch!"}`	Signature could not be verified
`{"status": false, "message": "failure", ...}`	Not eligible — a normal outcome

TBD No further error catalogue is published for this endpoint.

Security guidance

Verify the order before you call. The value of this path is that issuance follows a real, settled transaction — that only holds if you check.
Derive virtualId server-side from your authenticated session, never from client input.
Use your real transaction reference as extTransactionId so rewards can be reconciled against payments.

See Security best practices.

Request​

BDATA payload​

Example​

Response​

Decoded BDATA — card issued​

Decoded BDATA — no card​

Using the response​

Your transaction reference​

Errors​

Security guidance​

Next​