> ## Documentation Index
> Fetch the complete documentation index at: https://docs.treasuryprime.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

The Card Authorization Loop Endpoint is used to accept or reject a
card transaction.

A [Card Product](/reference/card-product) may have one
`card_auth_loop_endpoint_id` registered and the API will send an HTTP
request for every card authorization. When a card authorization comes
in, an HTTP POST request will be sent to the URL specified in the Card
Auth Loop Endpoint object. The value returned from that request will
determine if the authorization is rejected or not. See below for
details.

<Warning>
  You must have the `/card_auth_loop_endpoint` endpoint enabled in order to use this functionality.
</Warning>

### The Card Auth Loop Endpoint Protocol

For every card authorization, the Card Auth Loop Endpoint that is set
in the [Card Product](/reference/card-product)
`card_auth_loop_endpoint_id` is called.

When a card authorization comes in, an HTTP POST request will be sent
to the URL specified in the Card Auth Loop Endpoint object. The POST
receives a JSON body of a [Card Event](/reference/card-event) and must
return one of these HTTP codes:

| HTTP Code | Action | Meaning                                                  |
| --------- | ------ | -------------------------------------------------------- |
| 200       | accept | The authorization is accepted.                           |
| 402       | reject | The authorization is rejected and the transaction fails. |

You may optionally include a JSON body with your response to customize
the outcome:

* On a `200` response, you may include an `amount` field (a decimal
  string, e.g. `"10.00"`) to approve the transaction for less than the
  requested amount. If the field is omitted, or the value is not a
  positive number no greater than the requested amount, the full
  requested amount is approved. Note that a final balance check still
  takes place after your response is received, so the actual approved
  amount may be reduced further if funds are insufficient.

* On a `402` response, you may include a `decline_reason` field (a
  string, up to 255 characters) to attach a custom reason to the
  decline. This is appended to the standard `Card Auth Loop Endpoint
  Denied Request` decline reason (e.g. `Card Auth Loop Endpoint Denied
  Request - 082`) and surfaced in the resulting Card Event's
  `decline_reason` field.

* If no body, or an empty body, is returned, standard behavior applies
  (the full amount is approved, or the standard decline reason is
  used).

* Any other HTTP code is ignored and the default authorization
  behavior is run.

* If the HTTP response takes more that 1500 msec to return, the call
  is ignored and the default authorization behavior is run.

Note that a final balance check takes place after the authorization is
accepted. A transaction authorized using the Card Auth Loop Endpoint
may still be automatically declined due to insufficient funds. See the
[Managing Card Authorizations with the Card Auth Loop
Endpoint](/docs/managing-card-authorizations) guide for more details
including the default authorization behavior.