Need help?


Many of the responses contain common data elements; these are described in the following paragraphs.

Transaction type

This contains details of the transaction type. It includes both a text based name for the type, and a numeric type code.

    <name>Transaction type name</name>
     <code>Transaction type code</code>

The transaction types are as follows:

Sale1A standard online transaction. If authorised the relevant amount will be debited
from the customers’ card.
Void2A method used to cancel a sale transaction. This can only be done within a short
time after the sale transaction was processed. The void amount is always the
same as the original sale amount.
Refund3Used to credit an amount back to the customer. The refund amount may be the
same as or less than the original Sale amount.
Refund Reversal4This can be used to cancel a refund, and can only be done within a short time
after the refund was processed. Not all acquirers support this transaction type.
Auth5A pre-authorisation transaction. This is similar to a sale, but the amount is not
immediately debited from the customers’ card. Instead the amount is reserved
on that card, and can then be debited at a later date using a capture transaction.
Until the capture transaction is processed, no funds will be debited.
Release6Used to release any funds that have previously been reserved by an auth
transaction. No funds are debited from the card, and the capture option can no
longer be used.
Capture7Used to debit funds that have been previously reserved using an auth
transaction. This completes the transaction processing.
Capture Reversal8This can be used to cancel a capture transaction, and can only be done within a
short time after the capture was processed. Not all acquirers support this
transaction type.

Transaction class

    <name>Transaction type name</name>
     <code>Transaction type code</code>

The transaction classes are as follows:

Mail Order/Telephone Order1
Continuous Authority4

Authorisation results

Details of the transaction status. If the transaction was authorised, then the status will be ‘A’. If it has been authorised but placed on hold, the status will be ‘H’. Other status codes indicate that the transaction could not be processed. A list of transaction status codes can be found at the end of this document.

  <status>Authorisation status</status>
  <code>Authorisation code</code> 
  <message>Authorisation message</message>

Customer information

  <title>Customer title</title>
  <fname>Customer forename(s)</fname>
  <sname>Customer surname</sname>
  <addr1>Address line 1</addr1>
  <addr2>Address line 1</addr2>
  <addr3>Address line 1</addr3>
  <country>Country – full name</country>
  <country_iso>Country – 2 character ISO code</country_iso>
  <zip>Post/Area code</zip>
  <tel>Telephone number</tel>
  <email>Email address</email>

Transaction information

Individual transaction details

  <id>Transaction reference</id>
  <prev_id>Transaction reference of the previous transaction</prev_id>
  <init_id>Transaction reference of the initial transaction</init_id>
  <type>CDE: Transaction type</type>
  <class>CDE: Transaction class</class>
  <auth>CDE: Authorisation results</auth>
  <amount>Transaction amount</amount>
  <currency>Transaction currency</currency>
  <description>Transaction description</description>
  <cartid>Cart ID</cartid>
  <test>Test mode. 0=Live, 1=Test</test>
  <date>Transaction time and date, GMT</date>
    <id>Store ID</id>
    <name>Store name</name>
  <billing>CDE: Customer information</billing>
    <number>Card number. Only the first and last 4 digits are shown</number>
    <type>Card type, if known</type>
    <country_iso>Card issue country, if known</country_iso>
  <notecount>Number of notes attached to this transaction</notecount>
    -- repeated for each note attached to this transaction
    <text>Note text</text>
    <ref>Additional transaction related to this note, if any</ref>

For transactions which are a follow-up transaction, such as a void, the <prev_id> contains the transaction reference of the transaction being voided. For an initial transaction, such as a sale or auth, if it is set then it will be the same as the main transaction ID.

In a multi-transaction sequence, such as a refund being performed on a capture transaction, the <init_id> will contain the reference to the initial auth transaction.

Repeat billing agreement

Details of an individual repeat billing agreeement

  <id>Agreement ID </id>
    <id>Store ID</id>
    <name>Store name</name>
  <created>Time and date the agreement was created, GMT</created
  <status>Agreement status, numeric version</status>
  <statustxt>Agreement status, text version</statustxt>
  <currency>Agreement currency</currency>
  <initial>Initial transaction amount. 0 if no initial transaction.</initial>
    <period>Repeat billing period – weekly or monthly</period>
    <interval>Number of repeat billing periods between each transaction</interval>
    <day>Which day of the week or day of the month each transaction is on</day>
    <count>Maximum number of repeat transaction. 0 for no limit</count>
    <amount>Recurring transaction amount.</amount>
  <final>Final transaction amount for agreements with repeat limit.</final>
  <description>Agreement description</description>
    <description>Description to use for each transaction.</description>
    <cartid>Cart ID to use for each transaction</cartid>
    <test>Test mode. 0=Live, 1=Test</test>
  <custid>Customer ID</custid>
  <billing>CDE: Customer information (Optional, depends on service used)</billing> 

The agreement status codes are as follows:

Pending0Agreement is being setup and has not yet started
Running1Agreement is running normally
Completed2Agreement has completed (where a limit is set on the number of payments)
Failed3Agreement stopped due to multiple payment errors.
Overdue4Payment overdue. Only for agreements where payment is by invoice.
Cancelled5Agreement has been cancelled.