Authorise

Verify and reserve funds for secure transactions.

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

  1. Authorisation

    Confirm the credit card’s validity and reserve the intended amount on the card.

  2. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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>


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>


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 days1 25 USD3
    4112 Passenger railways 7 days1 25 USD3
    4131 Bus lines 7 days1 25 USD3
    5812 Eating places and restaurants end of approval day2 20%
    5813 Drinking places, bars, taverns, cocktail lounges, nightclubs, discotheques end of approval day2 20%
    4121 Taxicabs and limousines (card-absent environment only) end of approval day2 20%
    7 days1 The maximum authorisation timeframe is 7 days. For US merchant regions, this timeframe is 3 days.
    end of approval day2 The authorisation timeframe lasts until the end of the approval day in the acquirer’s timezone.
    25 USD3 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%