/v1/token/validateendpoint accepts a CardVerifyToken generated from
/v1/card/verifyendpoint 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.
token: stringCardVerifyToken from the
TokenValidateresponse JSON object
token_valid: booleanWhether this is a legitimate token belonging to a scan. If this is false, then this token is likely forged
card_verified: booleanWhether Bouncer believes this scan is a legitimate card on a legitimate device. False values represents Bouncer believing this is a high risk scan. If
failure_reasonswill be a non-empty list.
card_verify_attempt_at: stringISO8601 format of the timestamp when the scan was recorded by Bouncer servers
failure_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.