Authorize Cards
Now that the Card Present SDK is set up and a terminal is onboarded, you’re ready to authorize cards.
Verify a Card
Use the verify card function in order to verify that a card is valid. Note that this will not pre-authorize a card for any amount, it will simply verify that a card will not be declined due to being invalid, lost, or stolen. This function can only be used via the physical authorization flow.
Authorize a Card
There are two types of authorization supported by terminals; manual and physical. Manual authorization involves typing in the card data while physical authorization involves the terminal collecting the card data from a card interaction (chip, swipe, or tap).
| Event | Physical auth | Manual auth |
|---|---|---|
| Begin a transaction | Default “Pay Now” button in UI | Alternative key-in card button in UI |
| Prompt for tip | Depends on terminal’s tip config | |
| Prompt for card | Dip/swipe/tap card | Key the card info into the terminal |
| Process authorization | Terminal status of "Terminal is authorizing" | |
Physical Authorization
Create a trigger in your merchant-facing UI in order to begin an authorization. Note that simply initiating authorization does not require card info. For instance, your trigger could be a “Pay Now” button for a server to ring up a table, which will run the physical auth function.
The terminal will prompt the payer for tip information if tip.mode was set to prompt_on_terminal. If tip.mode was set to prompt_on_receipt or disabled, then this step will be skipped.
Next, the terminal will prompt the payer for a card, and once provided the Card Present SDK will provide a new Terminal status with Terminal is authorizing. If the authorization is successful, then the Card Present SDK will return a successful auth.
Manual Authorization
This authorization flow is the same as the physical authorization flow, except for the following:
- Your merchant-facing UI should have a separate trigger indicative of keying-in card information. For instance, a “Key in card to pay now” button.
- That trigger will initiate the Manual auth function.
Authorization Response
After the manual or physical authorization flow has been initiated, the Card Present SDK then authorizes the provided card information and returns a response. On a successful authorization, the Card Present SDK constructs a Payment Info and an Authorization Info object, which both get passed back to the delegate method:
| Payment Info | |
|---|---|
| Detail | Sub-Object Details |
| Payment method blob |
|
| Payer email | |
| Payment date | |
| Merchant receipt info | |
| Payer receipt info | |
| Authorization Info | |
| Detail | Sub-Object Details |
| Authorization Result |
|
| Amount | |
| Tip Amount | |
| Currency | |
| Authorization Code | |
| Offline? (boolean value) | |
| EMV information (for receipts) | |
Find the definitions of these results in the constants file of the Card Present SDK, and in the Classes section of the SDK documentation (found in the Card Present SDK package).
When the Card Present SDK responds with either approved or partially approved values for the authorization result, get the encoded payment method value from the payment info delegate.
Important
If the authorization was offline, store the encoded payment method along with the authorization amount and the merchant’s Account ID. Queue these to be processed via a POST /payments API request once the terminal is online again. Find more information in the deffered_authorization portion of the Configure a Terminal section.
At this point, a Payment does not exist. You’ll need to use the encoded payment method in the Payments API in order to charge the authorized card.
Next Up: Process Payments
Begin processing payments with a encoded payment methods.
- Use encoded payment methods
- Capture Payments
- Manage payment operations
Questions? Need help? Visit our support page!