Authorise

Verify and reserve funds for secure transactions.

When using authorisation transactions, you can do two essential things:

Authorisation
Confirm the credit card’s validity and reserve the intended amount on the card.
Capture
After successful authorisation, the reserved funds are charged to the customer’s account, finalising the transaction. See Capture for more information.

During the time between authorisation and capture, the specified amount is set aside, reducing the customer’s available credit limit. To avoid keeping these reservations indefinitely, emerchantpay’s system automatically cancels authorisations after a set period, usually around one week.

For most e-commerce situations, it’s a good practice to authorise the amount when you receive orders and then capture it when you ship the products. However, if your business deals with services or non-tangible goods, a sale transaction is a more efficient way to combine both authorisation and capture into one operation.

To initiate an authorisation, you have two pathways:

Standard authorisation transaction
You can start an authorisation using a standard authorisation transaction through the payment gateway. In this transaction, you include the necessary details to specify that it’s an authorisation. The gateway will then process this request according to the rules and timeframes defined by the card scheme of your customer.
Authorise 3D transaction
Alternatively, you can use an Authorise 3D transaction to initiate a pre-authorisation. Similar to the standard Authorisation transaction, you must include the preauthorization parameter to indicate the nature of the transaction. The gateway will then process this request according to the rules and timeframes defined by the card scheme of your customer. See 3D Secure for more information.

Both methods allow you to secure approval for an estimated transaction amount and provide flexibility in adjusting the transaction amount within the limits defined by the card brand.

Authorisation transaction workflow

In the payment process, authorisation is the first step when a customer initiates a purchase. Here’s a breakdown of the authorisation transaction workflow:

Authorisation request
You initiate the process with an authorisation request when a customer makes a purchase. This request is sent to the payment gateway, which communicates with the customer’s bank.
Payment details verification
The payment gateway verifies the customer’s payment details, such as the card number, expiration date, and security code. It also checks if the customer has sufficient funds or credit to cover the transaction.
Funds reservation
If the customer’s payment details are valid and funds are available, the bank reserves the specified amount on the customer’s credit card or bank account. This reserved amount is not yet transferred to you, it’s held temporarily to guarantee payment.

In certain situations, the issuer bank can decline the transaction due to various reasons, such as insufficient funds or the card being reported as lost or stolen. For more information, see issuer response codes.
Gateway response
The payment gateway promptly responds to the authorisation request. The response includes essential transaction details, such as a unique_id. This ID is vital for tracking and linking subsequent actions.
Transaction resolution
Based on the authorisation response, you can choose to proceed with a capture transaction to initiate the funds settlement, or you can void the authorisation if the customer decides not to proceed with the purchase.

Example of an authorisation request:

 <payment_transaction>
    <transaction_type>authorize</transaction_type>
    <transaction_id>119643250547501c79d8295</transaction_id>
    <usage>40208 concert tickets</usage>
    <remote_ip>245.253.2.12</remote_ip>
    <amount>100</amount>
    <currency>USD</currency>
    <card_holder>Travis Pastrana</card_holder>
    <card_number>4200000000000000</card_number>
    <expiration_month>12</expiration_month>
    <expiration_year>2024</expiration_year>
    <cvv>834</cvv>
    <customer_email>travis@example.com</customer_email>
    <customer_phone>+1987987987987</customer_phone>
    <billing_address>
      <first_name>Travis</first_name>
      <last_name>Pastrana</last_name>
      <address1>Muster Str. 12</address1>
      <zip_code>10178</zip_code>
      <city>Los Angeles</city>
      <state>CA</state>
      <country>US</country>
    </billing_address>
  </payment_transaction>

Example of a successful response:

<payment_response>
    <transaction_type>authorize</transaction_type>
    <status>approved</status>
    <mode>live</mode>
    <transaction_id>119643250547501c79d8295</transaction_id>
    <unique_id>44177a21403427eb96664a6d7e5d5d48</unique_id>
    <consumer_id>123456</consumer_id>
    <avs_response_code>5I</avs_response_code>
    <avs_response_text>Response provided by issuer processor; Address information not verified</avs_response_text>
    <cvv_result_code>M</cvv_result_code>
    <authorization_code>345678</authorization_code>
    <retrieval_reference_number>016813015184</retrieval_reference_number>
    <response_code>00</response_code>
    <timestamp>2023-08-29T14:00:46Z</timestamp>
    <descriptor>Descriptor one</descriptor>
    <amount>100</amount>
    <currency>USD</currency>
    <sent_to_acquirer>true</sent_to_acquirer>
    <scheme_transaction_identifier>019091214161031</scheme_transaction_identifier>
    <scheme_settlement_date>0830</scheme_settlement_date>
    <scheme_response_code>00</scheme_response_code>
 </payment_response>

See emerchantpay API for the complete list of authorisation transaction parameters and code samples.

Pre-authorisations

Pre-authorisations help you obtain approval for an estimated transaction amount. They are especially useful when the final transaction amount is uncertain, such as car rentals, hotel reservations, or fuel purchases. Pre-authorisations have two main functions – they validate the credit card and the cardholder, and they confirm the availability of funds.

Pre-authorisations share similarities with final authorisations but they differ in their extended authorisation timeframe and the ability to adjust the transaction amount within specific limits defined by the card scheme.

To initiate a pre-authorisation you must add the preauthorization paramater to your authorize or authorize3d transaction.

Example of a pre-authorisation request:

 <payment_transaction>
    <transaction_type>authorize</transaction_type>
    <transaction_id>TrxID_477f8aaf6348c3c17dc8979d66ebe894</transaction_id>
    <usage>40208 concert tickets</usage>
    <remote_ip>245.253.2.12</remote_ip>
    <amount>5000</amount>
    <currency>USD</currency>
    <preauthorization>true</preauthorization>
    <card_holder>Travis Pastrana</card_holder>
    <card_number>4200000000000000</card_number>
    <expiration_month>12</expiration_month>
    <expiration_year>2024</expiration_year>
    <cvv>834</cvv>
    <customer_email>travis@example.com</customer_email>
    <customer_phone>+1987987987987</customer_phone>
    <billing_address>
      <first_name>Travis</first_name>
      <last_name>Pastrana</last_name>
      <address1>Muster Str. 12</address1>
      <zip_code>10178</zip_code>
      <city>Los Angeles</city>
      <state>CA</state>
      <country>US</country>
    </billing_address>
  </payment_transaction>

Example of a successful response:

<payment_response>
    <transaction_type>authorize</transaction_type>
    <status>approved</status>
    <mode>live</mode>
    <transaction_id>TrxID_477f8aaf6348c3c17dc8979d66ebe894</transaction_id>
    <unique_id>6a3dc2181e7c99849362a40c5ffa2792</unique_id>
    <avs_response_code>5I</avs_response_code>
    <avs_response_text>Response provided by issuer processor; Address information not verified</avs_response_text>
    <cvv_result_code>M</cvv_result_code>
    <authorization_code>964969</authorization_code>
    <response_code>00</response_code>
    <timestamp>2023-08-29T14:01:02Z</timestamp>
    <descriptor>Descriptor one</descriptor>
    <amount>5000</amount>
    <currency>USD</currency>
    <sent_to_acquirer>true</sent_to_acquirer>
  </payment_response>

See emerchantpay API for the complete list of preauthorisation transaction parameters and code samples.

Card scheme-specific pre-authorisation details

Here are the specific pre-authorisation details for each card scheme:

Visa

MCC Restriction	Visa does not impose specific restrictions on the Merchant Category Code (MCC) for pre-authorisation.
Authorisation timeframe	-The maximum authorization timeframe for Visa pre-authorisations is 7 days. However, this timeframe may vary depending on the MCC and your region.
Authorisation timeframe extension	Visa does not support extensions for the authorisation timeframe.
Capture tolerance	Visa allows flexibility in capture tolerance, which can be specified in either a percentage or an exact amount. For further details on the MCCs where capture tolerance is applicable, refer to emerchantpay’s API.

MCC	Segment	Authorisation timeframe	Amount tolerance
3501-3999, 7011	Lodging	31 days	15%
3351-3500, 7512	Car rental	31 days	15%
4411	Steamship and cruise lines	31 days	15%
7513	Truck rentals	7 days	15%
7033	Trailer parks and campgrounds	7 days	15%
7519	Motor home and recreational vehicle rentals	7 days	15%
5552	Electric vehicle charging	7 days	15%
7523	Parking and garages	7 days	15%
7394	Equipment, tool, furniture, and appliance rental	7 days	none
7999	Recreation services	7 days	none
7996	Amusement parks, carnivals, circuses, fortune tellers	7 days	none
5599	Miscellaneous automotive, aircraft, and farm equipment dealers	7 days	none
4457	Boat rentals and leasing	7 days	none
5571	Motorcycle shops and dealers	7 days	none
4111	Local and suburban commuter, and passenger transportation, including ferries	7 days¹	25 USD³
4112	Passenger railways	7 days¹	25 USD³
4131	Bus lines	7 days¹	25 USD³
5812	Eating places and restaurants	end of approval day²	20%
5813	Drinking places, bars, taverns, cocktail lounges, nightclubs, discotheques	end of approval day²	20%
4121	Taxicabs and limousines (card-absent environment only)	end of approval day²	20%

7 days¹	The maximum authorisation timeframe is 7 days. For US merchant regions, this timeframe is 3 days.
end of approval day²	The authorisation timeframe lasts until the end of the approval day in the acquirer’s timezone.
25 USD³	A capture with an amount of up to 25 USD can be requested without the need for additional incremental authorisation. In cases where the authorised amount is less than 25 USD (15 USD for US region merchants), the corresponding amount will be converted to the transaction currency if it differs from USD.

Mastercard

MCC Restriction	Mastercard does not impose specific restrictions on the Merchant Category Code (MCC) for pre-authorisation.
Authorisation timeframe	The maximum authorization timeframe for Mastercard pre-authorisations is 30 days.
Authorisation timeframe extension	Mastercard supports authorisation timeframe extensions through the Incremental Authorise feature.
Capture tolerance	Mastercard allows capture tolerance, but it applies only to specific MCCs (Merchant Category Codes). For further details on the MCCs where capture tolerance is applicable, refer to emerchantpay’s API.

MCC	Segment	Authorisation timeframe	Amount tolerance
5812	Eating Places, restaurants	30 days	20%
5814	Fast food restaurants	30 days	20%

Maestro

MCC restriction	Maestro does not impose specific restrictions on the Merchant Category Code (MCC) for pre-authorisation.
Authorisation timeframe	The maximum authorisation timeframe for Maestro pre-authorisations is 7 days.
Authorisation timeframe extension	Maestro supports authorisation timeframe extensions through the Incremental Authorise feature.
Capture tolerance	Maestro allows capture tolerance, but it applies only to specific MCCs (Merchant Category Codes). For further details on the MCCs where capture tolerance is applicable, refer to emerchantpay’s API.

MCC	Segment	Authorisation timeframe	Amount tolerance
5812	Eating Places, restaurants	7 days	20%
5814	Fast food restaurants	7 days	20%

Was this page helpful?