The general flow for authorization using the Card Auth Loop Endpoint (CALE) is shown below:

Testing in the Developer Sandbox

  1. Create a new Card Auth Loop Endpoint.
  2. Update the 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.
  3. Create a new card_event.auth_request Card Simulation to mimic a card authorization taking place.
  4. 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).
  5. You now have 1500 milliseconds to respond with a 200 (to approve the request) or a 402 (to reject the request).
  6. 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

  1. Create a new Card Auth Loop Endpoint.
  2. Update the 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.
  3. Initiate authorization by swiping or submitting a virtual payment using a card issued under the Card Product from step 2.
  4. 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).
  5. You now have 1500 milliseconds to respond with a 200 (to approve the request) or a 402 (to reject the request).
  6. 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 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.

Example Card Auth Loop Endpoint Callback

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.

{
  "message_type": "auth-request",
  "amount": "25.00",
  "bank_id": "bank_treasuryprime",
  "org_id": "org_1evy4cx23n5",
  "decline_reason": null,
  "updated_at": "2022-05-26T19:43:05Z",
  "currency": "USD",
  "status": "pending",
  "id": "cnm_11h8zp29ahk22d",
  "card_id": "card_11h84t45a4d26",
  "trace_id": "aec7df65adb14c34989384d0hh44f897",
  "network": "mastercard",
  "network_created_at": null,
  "merchant": {
    "name": "Card Transaction Test 1",
    "mcc": "3501",
    "mid": "4445025949033",
    "address": {
      "city": "LAS VEGAS",
      "state": "NV",
      "postal_code": "88901",
      "country": "USA"
    }
  },
  "processor": "marqeta",
  "networkdata": null,
  "created_at": "2022-05-26T19:43:05Z",
  "atm": null
}

The general flow for authorization using the Card Auth Loop Endpoint (CALE) is shown below:

Testing in the Developer Sandbox

  1. Create a new Card Auth Loop Endpoint.
  2. Update the 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.
  3. Create a new card_event.auth_request Card Simulation to mimic a card authorization taking place.
  4. 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).
  5. You now have 1500 milliseconds to respond with a 200 (to approve the request) or a 402 (to reject the request).
  6. 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

  1. Create a new Card Auth Loop Endpoint.
  2. Update the 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.
  3. Initiate authorization by swiping or submitting a virtual payment using a card issued under the Card Product from step 2.
  4. 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).
  5. You now have 1500 milliseconds to respond with a 200 (to approve the request) or a 402 (to reject the request).
  6. 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 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.

Example Card Auth Loop Endpoint Callback

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.

{
  "message_type": "auth-request",
  "amount": "25.00",
  "bank_id": "bank_treasuryprime",
  "org_id": "org_1evy4cx23n5",
  "decline_reason": null,
  "updated_at": "2022-05-26T19:43:05Z",
  "currency": "USD",
  "status": "pending",
  "id": "cnm_11h8zp29ahk22d",
  "card_id": "card_11h84t45a4d26",
  "trace_id": "aec7df65adb14c34989384d0hh44f897",
  "network": "mastercard",
  "network_created_at": null,
  "merchant": {
    "name": "Card Transaction Test 1",
    "mcc": "3501",
    "mid": "4445025949033",
    "address": {
      "city": "LAS VEGAS",
      "state": "NV",
      "postal_code": "88901",
      "country": "USA"
    }
  },
  "processor": "marqeta",
  "networkdata": null,
  "created_at": "2022-05-26T19:43:05Z",
  "atm": null
}