Testing in the Developer Sandbox
- Create a new Card Auth Loop Endpoint.
- Update the
card_auth_loop_endpoint_id
of the Card Product you would like to receive authorization requests for with theid
of the Card Auth Loop Endpoint you created. - Create a new
card_event.auth_request
Card 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-request
Card 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_response
set 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_id
of the Card Product you would like to receive authorization requests for with theid
of 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-request
Card 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_response
set 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.