Integration Overview

Role of the Bouncer Mobile SDKs:
Scan the number side of a card
Generate a Card Verify payload based off of the scan. The payload contains intermediary fraud model results that our server needs to make a final decision.
Return the details of the scanned card and the Card Verify Payload for the server-to-server call
Note: The Bouncer SDK will not directly expose whether this was a legitimate scan of a real card to the client App. It’ll be up to the client App to pass the Card Verify Payload back to the client servers and make a subsequent server to server call to get the validation results.
Role of the Bouncer Server:
Verify the Card Verify payload generated by the Bouncer mobile SDK and return results of the scan
Endpoints
​/v1/card/verify (server-to-server): Processes the payload and returns a validation token
​/v1/token/validate (server-to-server): returns scan details
High level diagram (transaction-time challenge)
Typical Card Verify High Level Journey
High level diagram (Scan card up front, verify card if necessary later)
Card scanning to extract the PAN, when used top of funnel during user onboarding, has demonstrably shown a significant conversion bump by itself. Some implementors may want to use Card Verify to scan all cards, and only verify whether the scan is fraudulent or not later down the line if the user engages in a risky transaction. The following digram shows the typical setup for such a use case

Last modified 2yr ago