| Name | Description |
|---|---|
| reauthorization | This will indicate to the Acquirer that the Merchant is initiating a transaction without the cardholder actively participating so as to Re-Authorize the cardholder's card as part of one purchase (e.g. Split Shipment of goods). The Merchant can only send "reauthorization" if the card has an initial approved transaction (Pre-Auth or Sale) as card schemes require that details from the original transaction are sent in the Reauthorization. Merchants will need to supply the clientSystemTransactionId from the original transaction in the clientSystemInvoiceId so that ANYpay can lookup the card scheme reference data. |
| resubmission | This will indicate to the Acquirer that a Merchant is performing a resubmission in the case where it requested an authorization, but received a decline due to insufficient funds after it has already delivered the goods or services to the cardholder. Merchants in such scenarios can resubmit the request to recover outstanding debt from cardholders The Merchant can only send "resubmission" if the card has an initial declined transaction (Pre-Auth or Sale) as card schemes require that details from the original transaction attempt are sent in the Resubmission. Merchants will need to supply the clientSystemTransactionId from the original transactions in the clientSystemInvoiceId so that ANYpay can lookup the card scheme reference data. |
| delayedCharge | This will indicate to the Acquirer that a Merchant is performing a Delayed Charge transaction in order to process a supplemental account charge after original services have been rendered and respective payment has been processed. The Merchant can only send "delayedCharge" if the card has an initial approved transaction (Pre-Auth or Sale) as card schemes require that details from the original transaction attempt are sent in the No Show. Merchants will need to supply the clientSystemTransactionId from the original transactions in the clientSystemInvoiceId so that ANYpay can lookup the card scheme reference data. Only certain Merchant Types are eligible to send Delayed Charges, so please speak to your PXP representative to find out more. |
| noShow | This will indicate to the Acquirer that a Merchant is performing a No Show transaction in order to process a penalty charge according to the Merchant's cancellation policy when the Cardholder has used their card to guarantee a reservation will be honored. The Merchant can only send "noShow" if the card has an initial approved transaction (Pre-Auth or Sale) as card schemes require that details from the original transaction attempt are sent in the No Show. Merchants will need to supply the clientSystemTransactionId from the original transactions in the clientSystemInvoiceId so that ANYpay can lookup the card scheme reference data. Only certain Merchant Types are eligible to send No Show, so please speak to your PXP representative to find out more. |
| initialRecurring | This will indicate to the Acquirer that a Merchant is performing a first in a series of Recurring Transactions in order to authenticate the cardholder and setup the agreement for the merchant to initiate future transactions at regular intervals. In response to an initialRecurring Transaction, the Merchant will receive back Card Scheme Reference data in the cardSchemeReference element. Merchants must retain the Card Scheme Reference from the Initial Recurring Transaction and return it on the Subsequent Recurring Transactions within the cardSchemeReference element. |
| subsequentRecurring | This will indicate to the Acquirer that a Merchant is performing a Subsequent Recurring Transaction as part of an agreement with the cardholder that their card can be authorised at regular intervals. The Merchant can only send "subsequentRecurring" if they have performed an initialRecurring transaction in order to obtain Card Scheme Reference data. Merchants will need to supply cardSchemeReference from Initial Recurring Transactions on all Subsequent Recurring Transactions. |