Testing in the Developer Sandbox
- Create a new Card Auth Loop Endpoint.
- Update the
card_auth_loop_endpoint_idof the Card Product you would like to receive authorization requests for with theidof the Card Auth Loop Endpoint you created. - Create a new
card_event.auth_requestCard Simulation to mimic a card authorization taking place. - An HTTP POST request will be sent to the URL listed in the Card
Auth Loop Endpoint containing an
auth-requestCard Event in the message body (example below). - You now have 1500 milliseconds to respond with a 200 (to approve the request) or a 402 (to reject the request).
- If you do not respond, the
default_responseset in the Card Auth Loop Endpoint will take effect. Please see the warnings below.
Testing in Production
- Create a new Card Auth Loop Endpoint.
- Update the
card_auth_loop_endpoint_idof the Card Product you would like to receive authorization requests for with theidof the Card Auth Loop Endpoint you created. - Initiate authorization by swiping or submitting a virtual payment using a card issued under the Card Product from step 2.
- An HTTP POST request will be sent to the URL listed in the Card
Auth Loop Endpoint containing an
auth-requestCard Event in the message body (example below). - You now have 1500 milliseconds to respond with a 200 (to approve the request) or a 402 (to reject the request).
- If you do not respond, the
default_responseset in the Card Auth Loop Endpoint will take effect. Please see the warnings below.
Card Auth Loop Endpoint Default Response
You can set thedefault_response to "approved" or "denied", with
the standard setting being "approved".
Most of the time this setup is fine. If there is a timeout the card
still works as long as there is enough money in the account. However,
if you set
default_response to "denied" and your CALE system goes
offline then every single card swipe gets rejected. No exceptions.
That is the tradeoff.