Card Pre-Authorisations

📘

Applicability

Card Pre-Authorisations are only available for Visa and Mastercard cards products. They are not possible for the Maestro and Cirrus brands of Mastercard.

Overview

Card Pre-Authorisations may be useful in the following scenarios:

• The authorisation amount could differ from the final transaction amount.
• The payment may still be cancelled after the authorisation approval.
• Ordered goods may be shipped at different times (Split Shipment).
• A payment guarantee for up to 30 days is needed.

To support Card Pre-Authorisation functionality, PXP Financial offers the following payment methods:

Mastercard and Visa have different rules for their pre-authorisation functionality. The following limitations must be considered for selecting the correct payment method:

Mastercard PreAuthorisation

• increments are allowed
• multiple partial capture allowed (split shipment)
• authorisation expires after 30 days
• allowed for all MCCs

Visa Estimated Authorisation

• increments are allowed
• only one partial capture allowed (no split shipment)
• authorisation expires after 7-30 days, depending on the type of business of the merchant
• allowed for only specific MCCs (see below)

Visa MultiCapture Authorisation

• no increments are allowed
• multiple partial capture allowed (split shipment)
• authorisation expires after 7 days
• allowed for all MCCs

🚧

Multiple Partial Capture (Split Shipment)

The Multiple Partial Capture (Split Shipment) functionality for Mastercard PreAuthorisation and Visa MultiCapture Authorisation has been released on the PXP Live-Environment on October 10th 2019.

📘

Visa Estimated Authorisation - Merchant Industry restrictions

Visa Estimated Authorisations may only be used for Merchants categorised in one of the following MCCs/Segments:

• 3501-3999, 7011 Lodging
• 3351-3500, 7512 Car Rental
• 4411 Steamship and Cruise Lines
• 7513 Truck Rentals
• 7033 Trailer Parks and Campgrounds
• 7394 Equipment, Tool, Furniture and Appliance Rental
• 7519 Motor Home and Recreational Vehicle Rentals
• 7999 Recreation Services
• 7996 Amusement Parks, Carnivals, Circuses, Fortune Tellers
• 4111 Local and Suburban Commuter Passenger Transportation, including Ferries
• 4112 Passenger Railways
• 4131 Bus Lines
• 5812 Eating Places and Restaurants
• 5813 Drinking Places (Alcoholic Beverages), Bars, Taverns, Cocktail Lounges, Nightclubs and Discotheques
• 4121 Taxicabs and Limousines (Card-Absent Environment only)

Effective 18 October 2019, parking, electric vehicle charging and card-absent grocery merchants
may use estimated authorization and incremental authorization requests:

• 5552 Electric Vehicle Charging
• 7523 Parking Lots, Parking Meters and Garages
• 5411 Grocery Stores and Supermarkets (card-absent transactions)

The following table shows the expiration timelines for Visa Estimated Authorisations:

How to choose the correct authorisation method

Pre-Authorisations

The following table shows which payment method should be selected for which use-cases:

Final Authorisations

Normal Card Deposits (final authorisations) should be used in case:

• The authorisation amount is equal to the final transaction amount.
• It is unlikely that the payment needs to be cancelled after the authorisation approval.
• A payment guarantee for 7 days is sufficient (clearing must happen within 7 calendar days after the authorisation).

Typical examples when final authorisations (Card Deposits) should be used:

• Purchasing goods and services where the payment is made at time of delivery of the goods or services.

Integration

Payment method interaction type: Synchronous Execution (see Interaction Types).

The card pre/estimated/multicapture authorisation payments are very similar to card deposits. Payment methods interaction and states are the same as for Card Deposits (see Card Deposits and Card Deposits with 3DS2).
AuthorisedByProvider state in initiatePaymentResponse means successful authorisation. Any other state means that the authorisation is unsuccessful.

The only difference compared to Card Deposits is that card pre/estimated/multicapture authorisation payments will remain in state AuthorisedByProvider or go to Cancelled in case a full cancellation is done.
Any other requests for this payment (e.g. increment or partial capture) will result in separate transactions which are linked to the original card authorisation like it is done for card refunds or chargebacks.

How to partially capture a card pre-authorisation is explained in Capture Card Pre-Authorisations.

How to cancel a card pre-authorisation is explained in Cancel Card Pre-Authorisations.

📘

CVC and AVS for Card Pre-Authorisations

The CVC and AVS features can also be used with the payment methods Mastercard PreAuthorisation (304), Visa Estimated Authorisation (305) and Visa MultiCapture Authorisation (311). See Card Deposits with AVS for more details.

📘

EMV 3-D Secure (3DS)

The 3DS2 card holder authentication mechanism can also be used with the payment methods Mastercard PreAuthorisation (304), Visa Estimated Authorisation (305) and Visa MultiCapture Authorisation (311). See Browser Based Flow for 3DS2 for more details.

Redirect Integration

There are no specific steps for initiating Card Verifications with Redirect Integration. Refer to Initiate New Payment (Redirect) for the standard steps.

The configuration of the Pre-Authorisation payment methods for the PXP Financial Hosted Payment Pages has to be requested via PXP FinancialSupport.

Backend2Backend Integration

Example initiatePaymentRequest for a Visa Pre-Authorisation:

<?xml version="1.0" encoding="utf-8"?>
<initiatePaymentRequest xmlns="http://www.cqrpayments.com/PaymentProcessing" 
                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <merchantID>KalixaAcceptDEMO</merchantID>
  <shopID>KalixaAcceptDEMO</shopID>
	<merchantTransactionID>Order99999</merchantTransactionID>
	<paymentMethodID>305</paymentMethodID>
	<amount currencyCode="EUR">100</amount>
	<userID>u12312312</userID>
	<userData>
		<username>johndoe</username>
		<firstname>John</firstname>
		<lastname>Doe</lastname>
		<currencyCode>EUR</currencyCode>
		<languageCode>EN</languageCode>
		<email>[email protected]</email>
		<address>
			<street>Marxergasse</street>
			<houseNumber>1b</houseNumber>
			<postalCode>1030</postalCode>
			<city>Vienna</city>
			<countryCode2>AT</countryCode2>
			<telephoneNumber>00437778889999</telephoneNumber>
		</address>
		<dateOfBirth>1980-10-10T00:00:00</dateOfBirth>
		<gender>Male</gender>
	</userData>

	<userIP>127.0.0.1</userIP>
	<userSessionID>123</userSessionID>
	<creationTypeID>1</creationTypeID>

	<specificPaymentData>
		<data xsi:type="keyStringValuePair">
			<key>PaymentDescription</key>
			<value>some description</value>
		</data>
		<data xsi:type="keyStringValuePair">
			<key>PaymentDescriptionLanguageCode</key>
			<value>en</value>
		</data>
	</specificPaymentData>

	<paymentAccount>
		<specificPaymentAccountData>
			<data xsi:type="keyStringValuePair">
				<key>CardNumber</key>
				<value>4111111111111111</value>
			</data>
			<data xsi:type="keyStringValuePair">
				<key>CardVerificationCode</key>
				<value>111</value>
			</data>
			<data xsi:type="keyStringValuePair">
				<key>HolderName</key>
				<value>John Doe</value>
			</data>
			<data xsi:type="keyIntValuePair">
				<key>ExpiryMonth</key>
				<value>1</value>
			</data>
			<data xsi:type="keyIntValuePair">
				<key>ExpiryYear</key>
				<value>2099</value>
			</data>
		</specificPaymentAccountData>
	</paymentAccount>

</initiatePaymentRequest>

Example successful initiatePaymentResponse for a Visa Pre-Authorisation:

<?xml version="1.0" encoding="utf-8"?>
<initiatePaymentResponse xmlns="http://www.cqrpayments.com/PaymentProcessing"
                         xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <payment xsi:type="paymentWithPaymentAccount">
    <merchantID>KalixaAcceptDEMO</merchantID>
    <shopID>KalixaAcceptDEMO</shopID>
    <paymentMethod>
      <key>305</key>
      <value>Visa PreAuthorisation</value>
    </paymentMethod>
    <merchantTransactionID>Order99999</merchantTransactionID>
    <paymentID>47026705-e9e2-44c1-8f50-2b3676d60075</paymentID>
    <userID>u12312312</userID>
    <paymentProvider>
      <key>92</key>
      <value>CQRUK</value>
    </paymentProvider>
    <amount currencyCode="EUR">100.00</amount>
    <creationType>
      <key>1</key>
      <value>User</value>
    </creationType>
    <userIP>127.0.0.1</userIP>
		<state>
			<id>462890c3-2803-4b9f-b741-484ee8f73db3</id>
			<definition>
				<key>13</key>
				<value>AuthorisedByProvider</value>
			</definition>
			<createdOn>2014-12-11T11:45:16.7360552Z</createdOn>
			<description>Approved or completed successfully</description>
			<paymentStateDetails>
				<detail xsi:type="keyStringValuePair">
					<key>ProviderResponseCode</key>
					<value>0</value>
				</detail>
				<detail xsi:type="keyStringValuePair">
					<key>ApprovalCode</key>
					<value>442653</value>
				</detail>
			</paymentStateDetails>
		</state>
		<isExecuted>true</isExecuted>
		<baseAmount currencyCode="EUR">100</baseAmount>
		<paymentDetails xsi:nil="true"/>
		<paymentAccount>
			<paymentAccountID>3e27c7d9-e3d5-45df-8033-a78e66ab319e</paymentAccountID>
		</paymentAccount>
	</payment>
</initiatePaymentResponse>

Notifications

The standard notification mechanism is used for notifying the merchant in the background (asynchronously) about payment state changes. For more information see PaymentStateChangedNotification.