The allows you to accept or reject a card transaction at the time of authorization based on your business logic. To accomplish this, you assign the Card Auth Loop Endpoint to the Card Product whose card authorization requests you want to monitor. From there, any time a new authorization or refund authorization request is received for a card created using that Card Product, you will receive a callback at the URL specified in the Card Auth Loop Endpoint object.
The general flow for authorization using the Card Auth Loop Endpoint (CALE) is shown below:
card_auth_loop_endpoint_id
of the Card
Product you would like to receive
authorization requests for with the id
of the Card Auth Loop
Endpoint you created.card_event.auth_request
Card
Simulation to mimic a card
authorization taking place.auth-request
Card Event in the
message body (example below).default_response
set in the Card Auth
Loop Endpoint will take effect. Please see the warnings below.card_auth_loop_endpoint_id
of the Card
Product you would like to receive
authorization requests for with the id
of the Card Auth Loop
Endpoint you created.auth-request
Card Event in the
message body (example below).default_response
set in the Card Auth
Loop Endpoint will take effect. Please see the warnings below.You can set the default_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.
When a card authorization request is received, an HTTP POST will be sent to the URL specified in the Card Auth Loop Endpoint object. The POST body contains a Card Event object as shown below.
The allows you to accept or reject a card transaction at the time of authorization based on your business logic. To accomplish this, you assign the Card Auth Loop Endpoint to the Card Product whose card authorization requests you want to monitor. From there, any time a new authorization or refund authorization request is received for a card created using that Card Product, you will receive a callback at the URL specified in the Card Auth Loop Endpoint object.
The general flow for authorization using the Card Auth Loop Endpoint (CALE) is shown below:
card_auth_loop_endpoint_id
of the Card
Product you would like to receive
authorization requests for with the id
of the Card Auth Loop
Endpoint you created.card_event.auth_request
Card
Simulation to mimic a card
authorization taking place.auth-request
Card Event in the
message body (example below).default_response
set in the Card Auth
Loop Endpoint will take effect. Please see the warnings below.card_auth_loop_endpoint_id
of the Card
Product you would like to receive
authorization requests for with the id
of the Card Auth Loop
Endpoint you created.auth-request
Card Event in the
message body (example below).default_response
set in the Card Auth
Loop Endpoint will take effect. Please see the warnings below.You can set the default_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.
When a card authorization request is received, an HTTP POST will be sent to the URL specified in the Card Auth Loop Endpoint object. The POST body contains a Card Event object as shown below.