Validating a Card Verify Token
The
/v1/token/validate endpoint accepts a CardVerifyToken generated from /v1/card/verify endpoint and returns whether the Card Verify attempt corresponding to that token is valid or not. On invalid requests, the response will contain a list of failure_reasons around why Bouncer believes this Card Verify scan to be suspicious.Authentication Required
Request
Response
Returns a
TokenValidate response JSON objecttoken_valid: boolean Whether this is a legitimate token belonging to a scan. If this is false, then this token is likely forgedcard_verified: boolean Whether Bouncer believes this scan is a legitimate card on a legitimate device. False values represents Bouncer believing this is a high risk scan. If card_verified is true, failure_reasons will be a non-empty list.card_verify_attempt_at: string ISO8601 format of the timestamp when the scan was recorded by Bouncer serversfailure_reasons: list[string]) Contains a list of every reason Bouncer believes this scan was illegitimate. Only contains values if card_verified or token_valid is false. Full list of possible failure reasons:bin_mismatchPresent if there is a card design mismatch between what we expect from the BIN of the card challenged and the actual card that we scanned. On a Card Verify scan, we extract various design features on the card, like the presence and location of the Visa / MC logo, the chip, bank logo, etc to determine whether these design features match what we expect from the BIN of the card challenged.screen_detectedPresent if the card scanned does not appear to be a physical card. We check for whether the card appears to be a recaptured image on a screen (i.e. the user is scanning a picture of a card on another phone, or a Google Doc) or a card image that is printed on paper.card_number_mismatchPresent if the BIN (if provided in/v1/card/verify) and the last4 of the card that was challenged do not match the output of the corresponding scan.tampered_requestPresent if the request payload has been tampered with or is corrupt. For example, a man-in-the-middle attack that attempts to modify the request payload will trigger this failure reason.device_rate_limitedPresent if the device on which this scan was performed has hit a hardware rate limit. If this is present, it may indicate that an attacker is reusing the same device multiple times.
Successful Scan
{
"token_valid": true,
"card_verified": true,
"card_verify_attempt_at": "2019-10-23T00:48:07+0000",
"failure_reasons": []
}
Invalid Token
{
"token_valid": false,
"card_verified": false,
"card_verify_attempt_at": "2019-10-23T00:48:07+0000",
"failure_reasons": ["TOKEN_INVALID"]
}
Card not verified
{
"token_valid": true,
"card_verified": false,
"card_verify_attempt_at": "2019-10-23T00:48:07+0000",
"failure_reasons": [
"bin_mismatch",
"card_number_mismatch",
"screen_detected",
"tampered_request",
"device_rate_limited"
]
}
Last modified 2yr ago