For more information on how to integrate into this API, refer to https://developer.worldpay.com/docs/ipc/integration-direct.
On-premise installation of IPS.
Register a new Point of Sale device, by sending a message to the STOMP destination /v1/pos/registration
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to register a new Point of Sale.
The message to register a new Point of Sale.
A unique identifier for the Point of Sale.
A reference provided by the merchant for the Point of Sale.
A unique code to allow a Point of Sale to be activated.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive confirmation of the Point of Sale's registration.
Clients will receive a single reply on this destination in response to publishing on the following destinations:
/v1/pos/registration
Once received the client must disconnect from the web socket connection.
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the request.
Accepts the following message:
The message confirming the registration of a new Point of Sale.
The message confirming the registration of a new Point of Sale.
A unique key assigned to the POS to allow it to perform authenticated operations.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Initiate a new payment, by sending a message to the STOMP destination /v1/payment
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to initiate a new payment.
Message to start a new payment.
The type of payment.
sale
- Authorise and settle a payment from a customer for goods/services.refund
- Authorise and settle a payment to a customer for the return of goods/services.pre-auth
- Authorise a payment from a customer, but settle the payment separately using the payment/settle
channel.check-card
- Check and retrieve details of the customer's card, without taking a payment.check-card-payment
- Check and retrieve details of the customer's card, and wait for the payment request on this card.The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The instruction to start the payment.
The monetary value of the payment
The amount for the payment requested by the merchant in minor currency units.
Additional properties are allowed.
A description of the payment to appear in customer's transaction statements.
Currently only supported for Alipay payments.
First line of the narrative.
Additional properties are allowed.
For cross-channel refunds, provide the transaction reference from the original sale being refunded.
Must contain only alpha numeric, or these special characters:
! # $ % ( ) * + , - . / : ; = ? @ [ \ ] _ ` { } ~
For cross-channel refunds, provide the merchant code used in the original sale being refunded.
For refunding card sales, optionally provide the Payment Gateway Transaction Reference of the original sale being refunded.
For refunding Alipay sales, the original Gateway Transaction Reference is mandatory.
The method by which the payment should be made.
Details for a payment instrument captured by a payment device.
This payment instrument is supported for sale
, refund
, pre-auth
, check-card
and check-card-payment
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
Indicates whether the payment should be performed online or not. Defaults to true
if omitted on a payment where it is applicable.
Currently, an online/offline choice is only applicable to the check-card
and check-card-payment
payment types, online/offline processing is determined automatically for all other payments regardless of this indicator.
Additional properties are allowed.
Details for keying card details into the payment device for a pre-approved referral transaction.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The authorisation code for the payment obtained through a prior voice authorisation.
Optional for sale
payments, not required for refund
payments.
If omitted from a sale
payment, the authorisation code will be requested via the voice-authorisation
payment action request.
Additional properties are allowed.
Details for a token-based payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
A token representing a card used in a payment. This will be returned in the result of a card payment if tokenisation is enabled, and can be sent in the request for payment with a card/token
payment instrument.
The following token formats are supported:
Additional properties are allowed.
Details for a Alipay barcode payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The barcode value generated by the customer's Alipay app and scanned by the merchant.
An incrementing count of the number of attempts to send this barcode for this payment.
Defaults to 1 if not provided.
Quantity of the commodity in the payment. This value is shown in the consumer's transaction records list from Alipay.
Defaults to 1 if not provided.
Additional properties are allowed.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive real-time status updates for an in-flight payment, by subscribing to the STOMP destination /client/v1/payment/notification
.
Clients will receive multiple replies on this destination in response to publishing on the following destinations:
/v1/payment
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the payment.
Accepts the following message:
The message to communicate the real-time status of an in-flight payment.
Message with a notification about the payment flow which requires no action to be taken.
These can be displayed to the member of staff to inform them of the payment's progress.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Text describing an event occurring in the payment flow.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive a request to take an action in order to proceed with in-flight payment, by subscribing to the STOMP destination /client/v1/payment/action
.
Clients could receive multiple replies on this destination (if multiple actions are required) in response to publishing on the following destinations:
/v1/payment
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the payment.
Accepts the following message:
The message to request an action to proceed with the payment.
Message with details of an action to completed by the merchant.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Description of the action required for the payment.
The merchant is required to perform voice authorisation.
The action which is required to be performed to continue the payment.
Merchant identifiers to complete voice authorisation for this payment.
The payment gateway's merchant ID to identify the merchant.
Additional properties are allowed.
Referral contact details to complete voice authorisation for this payment.
Items:
The method of contact.
The value contact method, e.g. the phone number.
Additional properties are allowed.
Additional items are allowed.
Additional properties are allowed.
Merchant is required to confirm the customer's signature.
The action which is required to be performed to continue the payment.
Additional properties are allowed.
The merchant is required to approve the transaction based on AVS check results.
The action which is required to be performed to continue the payment.
Results of the payment's AVS check to be approved by the merchant.
Indicates if the CVV of the card matched during the AVS check.
Indicates if the cardholder address line(s) matched during the AVS check.
Indicates if the cardholder postal code matched during the AVS check.
Additional properties are allowed.
Additional properties are allowed.
Merchant is required provide a cashback amount.
The action which is required to be performed to continue the payment.
The maximum allowed amount of cash back available for the payment, in minor currency units.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Confirm the action taken for an in-flight payment, by sending a message to the STOMP destination /v1/payment/action
.
Clients should send a single message on this destination, and in the same session, for each message received on the client/v1/payment/action
destination. The content of the message received on that destination describes the required action details to be sent on this destination.
Accepts the following message:
The message to confirm the action for the payment has been completed.
Message with details of the action completed by the merchant.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The action taken by the POS to proceed with the payment.
Voice authorisation data.
The action which has been performed to continue the payment.
The authorisation code provided by the issuer, omitted if the transaction is not authorised.
Additional properties are allowed.
Signatured verfication data.
The action which has been performed to continue the payment.
Whether the signature was verified.
Additional properties are allowed.
AVS confirmation data.
The action which has been performed to continue the payment.
Whether AVS results are confirmed.
Additional properties are allowed.
Cashback data.
The action which has been performed to continue the payment.
The amount of cash back to be included in the payment, in minor currency units.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Abort a check card payment request, by sending a message to the STOMP destination /v1/payment/abort
.
Clients should send a this message in the same session as the original check-card-payment
payment request to indicate that they no longer wish to initiate a payment after the card has been checked.
Accepts the following message:
The message to abort a check card payment.
Message to abort a check card payment.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the content of the receipt(s) for the payment, by subscribing to the STOMP destination /client/v1/payment/receipt
.
Clients will receive multiple replies (one per receipt type) on this destination in response to publishing on the following destinations:
/v1/payment
/v1/payment/cancel
/v1/payment/query/receipt
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the payment.
Accepts the following message:
The message to receive a payment receipt.
Message with a receipt for a payment.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The type of receipt.
customer
- Customer copy of a receipt.merchant
- Merchant copy of a receipt.Base64 representation of the UTF-8 encoded content of the receipt.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the result of a completed payment, by subscribing to the STOMP destination /client/v1/payment/result
.
Clients will receive a single reply on this destination in response to publishing on the following destinations:
/v1/payment
/v1/payment/settle
/v1/payment/cancel
/v1/payment/query/result
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the payment.
Accepts the following message:
The message to communicate the result of a completed payment.
Message with payment results.
The list of completed payments, typically 1 payment but will be multiple in the case of a split payment done on the payment device.
Items:
Full details of a completed payment.
The type of payment that was requested.
sale
- Authorise and settle a payment from a customer for goods/services.refund
- Authorise and settle a payment to a customer for the return of goods/services.pre-auth
- Authorise a payment from a customer, but settle the payment separately using the payment/settle
channel.check-card
- Check and retrieve details of the customer's card, without taking a payment.check-card-payment
- Check and retrieve details of the customer's card, and wait for the payment request on this card.cancel
- The cancellation of a previously requested sale
, refund
, or pre-auth
.settle
- The settlement of a previously requested pre-auth
.The date-time at which the transaction was processed. Represented as a date-time according to RFC 3339, section 5.6, including the relevant time zone.
The code representing the result of payment request.
Succeeded
authorised-online
- The payment was authorised by card issuer, payment scheme or your acquirer.authorised-offline
- The payment was accepted locally by IPS.authorised-referral
- The payment was accepted locally by IPS on entry of a referral code by the POS attendant.keyed-recovery-success
- The keyed recovery payment was successfully stored by the Integrated POS gateway and will be submitted for settlement to your acquirer.pre-auth-completed
- The previously authorised transaction has been successfully flagged for settlement and will be submitted to your acquirer.succeeded
- The abort, cancel or settle request was processed successfully.Refused
refused-online
- The payment was refused by card issuer, payment scheme or your acquirer.refused-offline
- The payment was refused locally by IPS.refused-online-capture-card
- The payment was refused by card issuer, payment scheme or your acquirer and the card should be kept by the merchant.refused-avs-required
- The payment was refused by card issuer, payment scheme or your acquirer because AVS was required but not provided.Pending
started
- The payment process has started.in-progress
- The payment authorisation is in progress.auth-completed
- The payment authorisation process has completed. At this stage the payment record may not yet be saved to the Integrated POS gateway.Failed
cancelled
- The request process was cancelled by the merchant or customer.aborted
- The request was has been aborted unexpectedly.aborted-device-unavailable
- The request been aborted because the payment device is unavailable.aborted-busy
- The request been aborted because the system is currently busy.rejected-pre-auth
- The pre-authorisation request was rejected.rejected-card-number-not-matched
- The request was rejected because the card number did not match the expected value.rejected-card-expiry-date-not-matched
- The request was rejected because the card expiry date did not match the expected value.rejected-card-not-accepted
- The request was rejected because the card use is not accepted by the system.invalid-transaction-state
- The request cannot be performed on the transaction in its current state.invalid-operation
- The requested operation is not supported.invalid-gateway-transactions-reference
- The request cannot be processed because the gateway transaction reference is not recognised.invalid-merchant
- The request cannot be processed as the configured merchant details are invalid.invalid-terminal
- The request cannot be processed as the configured terminal details are invalid.invalid-merchant-status
- The request cannot be processed as merchant is not active.invalid-card-number
- The request cannot be processed as the card number is invalid.invalid-expired-card
- The request cannot be processed as the card has expired.invalid-issue-number
- The request cannot be processed as the card issuer number is invalid.invalid-card-expiry-date
- The request cannot be processed as the card expiry date is invalid.invalid-amount
- The requested sale or refund amount is not valid.denied-transaction
- The transaction was denied.denied-cashback
- The request for cashback was denied.pre-valid-card
- The request cannot be processed as the card is not yet valid.failed
- The request could not be processed.Details of the merchant.
Identifies the merchant that originates the payment.
The payment gateway's merchant ID to identify the merchant.
Additional properties are allowed.
Full details of the merchant.
The merchant's name.
The merchant's address.
Line 1 of the address
Line 2 of the address
Line 3 of the address
City of the address
State/County/Region of the address
Postal code (Post/Zip code) of the address
The 2-letter ISO-3166-1 country code of the address
Additional properties are allowed.
Additional properties are allowed.
The paypoint the request has been performed on.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The monetary value of the payment.
The full amount the customer's card has been charged or refunded including any gratuity, donations or cash back, in minor currency units.
The 3-letter ISO 4217 currency code which amounts are specified in.
The amount of cash back included in the payment, in minor currency units.
The amount of gratuity included in the payment, in minor currency units.
The amount of donation included in the payment, in minor currency units.
Data for Dynamic Currency Conversion if relevant to the payment.
The 3-letter ISO 4217 currency code which the amount was converted to.
The amount of the payment converted into the currency in minor currency units.
The conversion rate from the merchant's currency to the cardholder's local currency.
Additional properties are allowed.
Additional properties are allowed.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The transaction reference generated by the payment gateway to uniquely identify the payment. This will be available for any payment which has been processed online.
The transaction sequence number.
The retrieval reference number for the transaction.
The number of the receipt to be issued.
A retention reminder to include on receipts.
A customer declaration to include on receipts.
Base64 representation of the UTF-8 encoded content of the voucher.
The first 2 characters of each line a print command, followed by the text to print.
The print commands are:
01
- Print the Premier taxfree logo bitmap02
- Print large bold text, followed by a carriage return03
- Print large underlined text, followed by a carriage return04
- Print normal underlined text, followed by a carriage return05
- Print normal text, followed by a carriage return06
- Print normal sized bold text, followed by a carriage return07
- Print normal sized wide text, followed by a carriage return08
- Print normal right aligned text, followed by a carriage return09
- Print normal centre aligned text, followed by a carriage return10
- Print large bold centered text, followed by a carriage return11
- Print the data as a 'Interleaved 2 of 5' barcode12
- Print carriage return13
- Auto cut paper50
- Load another voucher51
- Print copy61
- The remainder of the text after the print code is encrypted and
base64 encoded. Decrypt it and then print normal text, followed by a carriage returnThe method by which the payment was made.
Details for a card-based payment instrument.
This payment instrument is supported for sale
, refund
, pre-auth
, check-card
and check-card-payment
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
Data for the card used in the payment.
A token representing a card used in a payment. This will be returned in the result of a card payment if tokenisation is enabled, and can be sent in the request for payment with a card/token
payment instrument.
The following token formats are supported:
The Primary Account Number of the card.
For whitelisted cards the full card number can be returned, for all other cards the number is masked. The first 6 digits and last 4 digits are returned, the middle digits are replaced by X
.
The expiry date of the card. Omitted if the card does not have an expiry date.
Additional properties are allowed.
The Track 2 data of the card as defined by ISO 7813. Available for whitelisted BIN ranges for check-card
and check-card-payment
transactions.
Indicator for the type of card. This field is omitted if the card type is unknown.
fuel
- The card used was a fuel card.debit
- The card used was a debit card.credit
- The card used was a credit card.A reference which can be used to identify the issuer of card.
amex
- Amexbank-of-america
- Bank of Americadankort
- DANKORTdiners
- Diners Club Internationaldiscover
- Discoverjcb
- JCBmaestro-uk
- UK Maestromaestro
- Maestromastercard-debit
- Debit Mastercardmastercard-purchasing
- Mastercard Purchasingmastercard
- Mastercardus-debit
- US Debitvisa-debit
- VISA DEBITvisa-electron-uk
- UK Electronvisa-purchasing
- Visa Purchasingvisa
- Visavisa-atm
- VISA ATMarval-phh
- ARVAL PHHflexecash-love-2-reward
- Flexecash Love 2 Rewardharvey-nichols
- HN PLCCharvey-nichols-mastercard
- HN Mastercardnewday-mastercard
- Newday MasterCardnewday-staff
- Newday Staff Cardnewday-store
- Newday Store PLCnewday-temporary
- Newday Temporarypps-gift
- PPS Gift Cardtesco-clubcard
- Tesco ClubcardNew values may be added without a software release.
The 3-digit numeric ISO 3166 code for the country the card was issued in.
The PAN Sequence number for ICC payments, and the card's issue number for swiped UK Maestro/Solo card payments.
The mnemonic associated with the application ID (AID) of the card used for the payment according to ISO/IEC 7816-5.
The application ID (AID) of the card used for the payment according to ISO/IEC 7816-5.
Note – For VISA Contactless Cards, truncated EMV Card Data Element Application Identifier (AID) will be received instead Extended AID.
The date from which the application can be used. Represented as a full-date according to RFC 3339, section 5.6.
Additional properties are allowed.
The method of reading the card. The current possible values are:
keyed
magstripe
integrated-circuit-chip
contactless-chip
contactless-magstripe
contactless-on-device
cardholder-not-present
New values may be added in future without a software release.
The verification method used for the cardholder. The current possible values are:
signature
pin-or-consumer-device
pin-and-signature
cardholder-not-present
none
unknown
New values may be added in future without a software release.
Indicates whether the payment request was handled online or not.
Currently, this is only applicable to check-card
and check-card-payment
payment types.
Data for the authorisation of the payment.
The authorisation code generated by the issuer for an authorised payment.
Additional response data containing the CVV response.
Additional properties are allowed.
Transaction Status Information (TSI), present only in case of an ICC payment. Used for debug purpose only.
Transaction Verification Results (TVR), present only in case of an ICC payment. Used for debug purpose only.
Additional properties are allowed.
Additional properties are allowed.
Details for a Alipay barcode payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The barcode value generated by the customer's Alipay app and scanned by the merchant.
Additional properties are allowed.
Additional properties are allowed.
Additional items are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive confirmation that the payment process has completed, by subscribing to the STOMP destination /client/v1/payment/complete
.
Clients will receive a single reply on this destination in response to publishing on the following destinations:
/v1/payment
/v1/payment/settle
/v1/payment/cancel
Once received the client must disconnect from the web socket connection.
Accepts the following message:
The message communicate that the payment process is complete.
Message confirming the payment process has completed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Settle a previous pre-authorised payment, by sending a message to the STOMP destination /v1/payment/settle
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to settle a pre-authorised payment.
Message to settle a previously requested pre-auth payment.
The Merchant Transaction Reference of the pre-auth payment to settle.
The Payment Gateway Transaction Reference (PGTR) of the pre-auth payment to settle.
The final monetary value to settle, may be different to the original pre-auth payment.
The amount for the payment requested to be settled by the merchant in minor currency units.
Additional properties are allowed.
The method by which the original payment was made.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
All card payment instruments (card/present
, card/keyed
, card/not-present
, card/token
) are covered.
The masked card number of the card used in the original payment to check against.
The expiry date of the card used in the original payment to check against.
Additional properties are allowed.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Cancel a previous payment, by sending a message to the STOMP destination /v1/payment/cancel
.
Cancelling a card payment prevents it from being sent for settlement, however the authorisation is not reversed. This means the funds ring-fenced in the customers account will not be released immediately. Funds will be released according to the card issuer's policy, typically 3 to 5 days.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to cancel a previous payment.
Message to cancel a payment.
The Merchant Transaction Reference of the payment to cancel.
The Payment Gateway Transaction Reference (PGTR) of the payment to cancel. This must be provided for any payment which has been assigned a PGTR.
The method by which the original payment was made.
Details to validate against a previous card-based payment instrument.
This payment instrument is supported for sale
, refund
and pre-auth
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
All card payment instruments (card/present
, card/keyed
, card/not-present
, card/token
) are covered.
The masked card number of the card used in the original payment to check against.
The expiry date of the card used in the original payment to check against.
Additional properties are allowed.
Additional properties are allowed.
Details for a Alipay barcode payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The barcode value generated by the customer's Alipay app and scanned by the merchant.
An incrementing count of the number of attempts to send this barcode for this payment.
Defaults to 1 if not provided.
Quantity of the commodity in the payment. This value is shown in the consumer's transaction records list from Alipay.
Defaults to 1 if not provided.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Query the result of the last payment, by sending a message to the STOMP destination /v1/payment/query/result
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to query the result of the last payment.
Message to query the last payment result.
Note that the transaction reference is required here to ensure that the expected payment result is returned.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Query the receipt of the last payment, by sending a message to the STOMP destination /v1/payment/query/receipt
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to query the receipt of the last payment.
Message to query the receipt for the last payment.
Note that the transaction reference is required here to ensure that the expected payment receipt is returned.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The type of receipt.
customer
- Customer copy of a receipt.merchant
- Merchant copy of a receipt.Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Request an X or Z Report for the current batch, by sending a message to the STOMP destination /v1/payment/report/batch
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to request an X or Z Report for the transactions in the current batch.
The message to request an X or Z Report for the transactions in the current batch.
Whether the close the current batch once the report is generated.
Keeping the batch open is also known as an "X Report".
Closing the batch is also known as a "Z Report".
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the X or Z Report for the current batch, by subscribing to the STOMP destination /client/v1/payment/report/batch
.
Clients will receive a single reply on this destination in response to publishing on the following destinations:
/v1/payment/report/batch
Once received the client must disconnect from the web socket connection.
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the request.
Accepts the following message:
The message to receive an X or Z Report for the transactions in the current batch.
The message to receive a report for the transactions in the current batch.
The paypoint associated with the batch.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The current batch number.
The 3-letter ISO 4217 currency code which amounts are specified in.
The total number of sales in the batch.
The total number of sales in the batch.
The total value of all sales in the batch in minor currency units.
The total value of all refunds in the batch in minor currency units.
A report for the current batch.
The current batch number.
The date-time at which report was generated. Represented as a date-time according to RFC 3339, section 5.6, including the relevant time zone.
A breakdown of the report by card scheme.
Items:
A report of the transactions for a specific card scheme in the batch.
The card scheme.
The total number of credit transactions.
The total value of all credit transactions in minor currency units.
The total number of debit transactions.
The total value of all credit transactions in minor currency units.
Additional properties are allowed.
Additional items are allowed.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Request details of stored offline transactions, by sending a message to the STOMP destination /v1/payment/report/offline
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to request details of stored offline transactions.
The message to request details for offline stored transactions.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the details of stored offline transactions, by subscribing to the STOMP destination /client/v1/payment/report/offline
.
Clients will receive a single reply on this destination in response to publishing on the following destinations:
/v1/payment/report/offline
Once received the client must disconnect from the web socket connection.
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the request.
Accepts the following message:
The message to receive details of stored offline transactions.
The message to receive details for offline stored transactions.
The paypoint associated the stored transactions.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The total number transactions currently stored offline.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the latest status of the connected payment device, by subscribing to the STOMP destination /client/v1/device/status
.
Clients will receive a message on this destination to confirm the current status of the payment device. Once received the client should disconnect from the web socket connection.
Accepts the following message:
The message to receive the status of the connected payment device.
Message confirming the status of the connected payment device.
The current status of the payment device.
The paypoint that the payment device is connected to.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The connected payment device.
The serial number of the payment device.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the latest status of the payment service, by subscribing to the STOMP destination /client/v1/service/status
.
Clients will receive a message on this destination to confirm the current status of the payment service. Once received the client must disconnect from the web socket connection.
Accepts the following message:
The message to receive the status of the payment service.
Message confirming the status of the payment service.
The current status of the payment service.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Request the restart of the payment device, by sending a message to the STOMP destination /v1/device/restart
.
Each request must be made in a new web socket connection.
Accepts the following message:
The message to request the restart of connected payment device.
The message to request the restart of connected payment device.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive the details the device restart request, by subscribing to the STOMP destination /client/v1/device/restart
.
Clients will receive a single reply on this destination in response to publishing on the following destinations:
/v1/device/restart
Once received the client must disconnect from the web socket connection.
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the request.
Accepts the following message:
The message to receive the result of the payment device restart request.
The message to receive the result of the payment device restart request.
The result of the request to restart the payment device.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
Receive errors that have occurring during processing a request, by subscribing to the STOMP destination /client/v1/error
.
All errors indicate the end of the request processing, and can be received in response to any request. Once received the client must disconnect from the web socket connection.
Replies are always sent to the same client session that sent the original request, so connections must remain active for the duration of the request.
Accepts the following message:
The message to receive errors that occur while processing a request.
Message to communicate an error has occurred while processing the request.
A specific error code identifying the error scenario.
A short message describing cause of error.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to register a new Point of Sale.
The message to register a new Point of Sale.
A unique identifier for the Point of Sale.
A reference provided by the merchant for the Point of Sale.
A unique code to allow a Point of Sale to be activated.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message confirming the registration of a new Point of Sale.
The message confirming the registration of a new Point of Sale.
A unique key assigned to the POS to allow it to perform authenticated operations.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to initiate a new payment.
Message to start a new payment.
The type of payment.
sale
- Authorise and settle a payment from a customer for goods/services.refund
- Authorise and settle a payment to a customer for the return of goods/services.pre-auth
- Authorise a payment from a customer, but settle the payment separately using the payment/settle
channel.check-card
- Check and retrieve details of the customer's card, without taking a payment.check-card-payment
- Check and retrieve details of the customer's card, and wait for the payment request on this card.The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The instruction to start the payment.
The monetary value of the payment
The amount for the payment requested by the merchant in minor currency units.
Additional properties are allowed.
A description of the payment to appear in customer's transaction statements.
Currently only supported for Alipay payments.
First line of the narrative.
Additional properties are allowed.
For cross-channel refunds, provide the transaction reference from the original sale being refunded.
Must contain only alpha numeric, or these special characters:
! # $ % ( ) * + , - . / : ; = ? @ [ \ ] _ ` { } ~
For cross-channel refunds, provide the merchant code used in the original sale being refunded.
For refunding card sales, optionally provide the Payment Gateway Transaction Reference of the original sale being refunded.
For refunding Alipay sales, the original Gateway Transaction Reference is mandatory.
The method by which the payment should be made.
Details for a payment instrument captured by a payment device.
This payment instrument is supported for sale
, refund
, pre-auth
, check-card
and check-card-payment
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
Indicates whether the payment should be performed online or not. Defaults to true
if omitted on a payment where it is applicable.
Currently, an online/offline choice is only applicable to the check-card
and check-card-payment
payment types, online/offline processing is determined automatically for all other payments regardless of this indicator.
Additional properties are allowed.
Details for keying card details into the payment device for a pre-approved referral transaction.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The authorisation code for the payment obtained through a prior voice authorisation.
Optional for sale
payments, not required for refund
payments.
If omitted from a sale
payment, the authorisation code will be requested via the voice-authorisation
payment action request.
Additional properties are allowed.
Details for a token-based payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
A token representing a card used in a payment. This will be returned in the result of a card payment if tokenisation is enabled, and can be sent in the request for payment with a card/token
payment instrument.
The following token formats are supported:
Additional properties are allowed.
Details for a Alipay barcode payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The barcode value generated by the customer's Alipay app and scanned by the merchant.
An incrementing count of the number of attempts to send this barcode for this payment.
Defaults to 1 if not provided.
Quantity of the commodity in the payment. This value is shown in the consumer's transaction records list from Alipay.
Defaults to 1 if not provided.
Additional properties are allowed.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to communicate the real-time status of an in-flight payment.
Message with a notification about the payment flow which requires no action to be taken.
These can be displayed to the member of staff to inform them of the payment's progress.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Text describing an event occurring in the payment flow.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to request an action to proceed with the payment.
Message with details of an action to completed by the merchant.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Description of the action required for the payment.
The merchant is required to perform voice authorisation.
The action which is required to be performed to continue the payment.
Merchant identifiers to complete voice authorisation for this payment.
The payment gateway's merchant ID to identify the merchant.
Additional properties are allowed.
Referral contact details to complete voice authorisation for this payment.
Items:
The method of contact.
The value contact method, e.g. the phone number.
Additional properties are allowed.
Additional items are allowed.
Additional properties are allowed.
Merchant is required to confirm the customer's signature.
The action which is required to be performed to continue the payment.
Additional properties are allowed.
The merchant is required to approve the transaction based on AVS check results.
The action which is required to be performed to continue the payment.
Results of the payment's AVS check to be approved by the merchant.
Indicates if the CVV of the card matched during the AVS check.
Indicates if the cardholder address line(s) matched during the AVS check.
Indicates if the cardholder postal code matched during the AVS check.
Additional properties are allowed.
Additional properties are allowed.
Merchant is required provide a cashback amount.
The action which is required to be performed to continue the payment.
The maximum allowed amount of cash back available for the payment, in minor currency units.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to confirm the action for the payment has been completed.
Message with details of the action completed by the merchant.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The action taken by the POS to proceed with the payment.
Voice authorisation data.
The action which has been performed to continue the payment.
The authorisation code provided by the issuer, omitted if the transaction is not authorised.
Additional properties are allowed.
Signatured verfication data.
The action which has been performed to continue the payment.
Whether the signature was verified.
Additional properties are allowed.
AVS confirmation data.
The action which has been performed to continue the payment.
Whether AVS results are confirmed.
Additional properties are allowed.
Cashback data.
The action which has been performed to continue the payment.
The amount of cash back to be included in the payment, in minor currency units.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to abort a check card payment.
Message to abort a check card payment.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive a payment receipt.
Message with a receipt for a payment.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The type of receipt.
customer
- Customer copy of a receipt.merchant
- Merchant copy of a receipt.Base64 representation of the UTF-8 encoded content of the receipt.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to communicate the result of a completed payment.
Message with payment results.
The list of completed payments, typically 1 payment but will be multiple in the case of a split payment done on the payment device.
Items:
Full details of a completed payment.
The type of payment that was requested.
sale
- Authorise and settle a payment from a customer for goods/services.refund
- Authorise and settle a payment to a customer for the return of goods/services.pre-auth
- Authorise a payment from a customer, but settle the payment separately using the payment/settle
channel.check-card
- Check and retrieve details of the customer's card, without taking a payment.check-card-payment
- Check and retrieve details of the customer's card, and wait for the payment request on this card.cancel
- The cancellation of a previously requested sale
, refund
, or pre-auth
.settle
- The settlement of a previously requested pre-auth
.The date-time at which the transaction was processed. Represented as a date-time according to RFC 3339, section 5.6, including the relevant time zone.
The code representing the result of payment request.
Succeeded
authorised-online
- The payment was authorised by card issuer, payment scheme or your acquirer.authorised-offline
- The payment was accepted locally by IPS.authorised-referral
- The payment was accepted locally by IPS on entry of a referral code by the POS attendant.keyed-recovery-success
- The keyed recovery payment was successfully stored by the Integrated POS gateway and will be submitted for settlement to your acquirer.pre-auth-completed
- The previously authorised transaction has been successfully flagged for settlement and will be submitted to your acquirer.succeeded
- The abort, cancel or settle request was processed successfully.Refused
refused-online
- The payment was refused by card issuer, payment scheme or your acquirer.refused-offline
- The payment was refused locally by IPS.refused-online-capture-card
- The payment was refused by card issuer, payment scheme or your acquirer and the card should be kept by the merchant.refused-avs-required
- The payment was refused by card issuer, payment scheme or your acquirer because AVS was required but not provided.Pending
started
- The payment process has started.in-progress
- The payment authorisation is in progress.auth-completed
- The payment authorisation process has completed. At this stage the payment record may not yet be saved to the Integrated POS gateway.Failed
cancelled
- The request process was cancelled by the merchant or customer.aborted
- The request was has been aborted unexpectedly.aborted-device-unavailable
- The request been aborted because the payment device is unavailable.aborted-busy
- The request been aborted because the system is currently busy.rejected-pre-auth
- The pre-authorisation request was rejected.rejected-card-number-not-matched
- The request was rejected because the card number did not match the expected value.rejected-card-expiry-date-not-matched
- The request was rejected because the card expiry date did not match the expected value.rejected-card-not-accepted
- The request was rejected because the card use is not accepted by the system.invalid-transaction-state
- The request cannot be performed on the transaction in its current state.invalid-operation
- The requested operation is not supported.invalid-gateway-transactions-reference
- The request cannot be processed because the gateway transaction reference is not recognised.invalid-merchant
- The request cannot be processed as the configured merchant details are invalid.invalid-terminal
- The request cannot be processed as the configured terminal details are invalid.invalid-merchant-status
- The request cannot be processed as merchant is not active.invalid-card-number
- The request cannot be processed as the card number is invalid.invalid-expired-card
- The request cannot be processed as the card has expired.invalid-issue-number
- The request cannot be processed as the card issuer number is invalid.invalid-card-expiry-date
- The request cannot be processed as the card expiry date is invalid.invalid-amount
- The requested sale or refund amount is not valid.denied-transaction
- The transaction was denied.denied-cashback
- The request for cashback was denied.pre-valid-card
- The request cannot be processed as the card is not yet valid.failed
- The request could not be processed.Details of the merchant.
Identifies the merchant that originates the payment.
The payment gateway's merchant ID to identify the merchant.
Additional properties are allowed.
Full details of the merchant.
The merchant's name.
The merchant's address.
Line 1 of the address
Line 2 of the address
Line 3 of the address
City of the address
State/County/Region of the address
Postal code (Post/Zip code) of the address
The 2-letter ISO-3166-1 country code of the address
Additional properties are allowed.
Additional properties are allowed.
The paypoint the request has been performed on.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The monetary value of the payment.
The full amount the customer's card has been charged or refunded including any gratuity, donations or cash back, in minor currency units.
The 3-letter ISO 4217 currency code which amounts are specified in.
The amount of cash back included in the payment, in minor currency units.
The amount of gratuity included in the payment, in minor currency units.
The amount of donation included in the payment, in minor currency units.
Data for Dynamic Currency Conversion if relevant to the payment.
The 3-letter ISO 4217 currency code which the amount was converted to.
The amount of the payment converted into the currency in minor currency units.
The conversion rate from the merchant's currency to the cardholder's local currency.
Additional properties are allowed.
Additional properties are allowed.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The transaction reference generated by the payment gateway to uniquely identify the payment. This will be available for any payment which has been processed online.
The transaction sequence number.
The retrieval reference number for the transaction.
The number of the receipt to be issued.
A retention reminder to include on receipts.
A customer declaration to include on receipts.
Base64 representation of the UTF-8 encoded content of the voucher.
The first 2 characters of each line a print command, followed by the text to print.
The print commands are:
01
- Print the Premier taxfree logo bitmap02
- Print large bold text, followed by a carriage return03
- Print large underlined text, followed by a carriage return04
- Print normal underlined text, followed by a carriage return05
- Print normal text, followed by a carriage return06
- Print normal sized bold text, followed by a carriage return07
- Print normal sized wide text, followed by a carriage return08
- Print normal right aligned text, followed by a carriage return09
- Print normal centre aligned text, followed by a carriage return10
- Print large bold centered text, followed by a carriage return11
- Print the data as a 'Interleaved 2 of 5' barcode12
- Print carriage return13
- Auto cut paper50
- Load another voucher51
- Print copy61
- The remainder of the text after the print code is encrypted and
base64 encoded. Decrypt it and then print normal text, followed by a carriage returnThe method by which the payment was made.
Details for a card-based payment instrument.
This payment instrument is supported for sale
, refund
, pre-auth
, check-card
and check-card-payment
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
Data for the card used in the payment.
A token representing a card used in a payment. This will be returned in the result of a card payment if tokenisation is enabled, and can be sent in the request for payment with a card/token
payment instrument.
The following token formats are supported:
The Primary Account Number of the card.
For whitelisted cards the full card number can be returned, for all other cards the number is masked. The first 6 digits and last 4 digits are returned, the middle digits are replaced by X
.
The expiry date of the card. Omitted if the card does not have an expiry date.
Additional properties are allowed.
The Track 2 data of the card as defined by ISO 7813. Available for whitelisted BIN ranges for check-card
and check-card-payment
transactions.
Indicator for the type of card. This field is omitted if the card type is unknown.
fuel
- The card used was a fuel card.debit
- The card used was a debit card.credit
- The card used was a credit card.A reference which can be used to identify the issuer of card.
amex
- Amexbank-of-america
- Bank of Americadankort
- DANKORTdiners
- Diners Club Internationaldiscover
- Discoverjcb
- JCBmaestro-uk
- UK Maestromaestro
- Maestromastercard-debit
- Debit Mastercardmastercard-purchasing
- Mastercard Purchasingmastercard
- Mastercardus-debit
- US Debitvisa-debit
- VISA DEBITvisa-electron-uk
- UK Electronvisa-purchasing
- Visa Purchasingvisa
- Visavisa-atm
- VISA ATMarval-phh
- ARVAL PHHflexecash-love-2-reward
- Flexecash Love 2 Rewardharvey-nichols
- HN PLCCharvey-nichols-mastercard
- HN Mastercardnewday-mastercard
- Newday MasterCardnewday-staff
- Newday Staff Cardnewday-store
- Newday Store PLCnewday-temporary
- Newday Temporarypps-gift
- PPS Gift Cardtesco-clubcard
- Tesco ClubcardNew values may be added without a software release.
The 3-digit numeric ISO 3166 code for the country the card was issued in.
The PAN Sequence number for ICC payments, and the card's issue number for swiped UK Maestro/Solo card payments.
The mnemonic associated with the application ID (AID) of the card used for the payment according to ISO/IEC 7816-5.
The application ID (AID) of the card used for the payment according to ISO/IEC 7816-5.
Note – For VISA Contactless Cards, truncated EMV Card Data Element Application Identifier (AID) will be received instead Extended AID.
The date from which the application can be used. Represented as a full-date according to RFC 3339, section 5.6.
Additional properties are allowed.
The method of reading the card. The current possible values are:
keyed
magstripe
integrated-circuit-chip
contactless-chip
contactless-magstripe
contactless-on-device
cardholder-not-present
New values may be added in future without a software release.
The verification method used for the cardholder. The current possible values are:
signature
pin-or-consumer-device
pin-and-signature
cardholder-not-present
none
unknown
New values may be added in future without a software release.
Indicates whether the payment request was handled online or not.
Currently, this is only applicable to check-card
and check-card-payment
payment types.
Data for the authorisation of the payment.
The authorisation code generated by the issuer for an authorised payment.
Additional response data containing the CVV response.
Additional properties are allowed.
Transaction Status Information (TSI), present only in case of an ICC payment. Used for debug purpose only.
Transaction Verification Results (TVR), present only in case of an ICC payment. Used for debug purpose only.
Additional properties are allowed.
Additional properties are allowed.
Details for a Alipay barcode payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The barcode value generated by the customer's Alipay app and scanned by the merchant.
Additional properties are allowed.
Additional properties are allowed.
Additional items are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message communicate that the payment process is complete.
Message confirming the payment process has completed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to settle a pre-authorised payment.
Message to settle a previously requested pre-auth payment.
The Merchant Transaction Reference of the pre-auth payment to settle.
The Payment Gateway Transaction Reference (PGTR) of the pre-auth payment to settle.
The final monetary value to settle, may be different to the original pre-auth payment.
The amount for the payment requested to be settled by the merchant in minor currency units.
Additional properties are allowed.
The method by which the original payment was made.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
All card payment instruments (card/present
, card/keyed
, card/not-present
, card/token
) are covered.
The masked card number of the card used in the original payment to check against.
The expiry date of the card used in the original payment to check against.
Additional properties are allowed.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to cancel a previous payment.
Message to cancel a payment.
The Merchant Transaction Reference of the payment to cancel.
The Payment Gateway Transaction Reference (PGTR) of the payment to cancel. This must be provided for any payment which has been assigned a PGTR.
The method by which the original payment was made.
Details to validate against a previous card-based payment instrument.
This payment instrument is supported for sale
, refund
and pre-auth
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
All card payment instruments (card/present
, card/keyed
, card/not-present
, card/token
) are covered.
The masked card number of the card used in the original payment to check against.
The expiry date of the card used in the original payment to check against.
Additional properties are allowed.
Additional properties are allowed.
Details for a Alipay barcode payment instrument.
This payment instrument is supported for sale
and refund
payment types.
The type of payment instrument. This will also dictate which other payment instrument fields are required to fulfil the payment.
The barcode value generated by the customer's Alipay app and scanned by the merchant.
An incrementing count of the number of attempts to send this barcode for this payment.
Defaults to 1 if not provided.
Quantity of the commodity in the payment. This value is shown in the consumer's transaction records list from Alipay.
Defaults to 1 if not provided.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to query the result of the last payment.
Message to query the last payment result.
Note that the transaction reference is required here to ensure that the expected payment result is returned.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to query the receipt of the last payment.
Message to query the receipt for the last payment.
Note that the transaction reference is required here to ensure that the expected payment receipt is returned.
The transaction reference defined by the merchant to uniquely identify the payment. Must contain only alpha numeric, hypen (-) and underscore (_) characters.
The type of receipt.
customer
- Customer copy of a receipt.merchant
- Merchant copy of a receipt.Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to request an X or Z Report for the transactions in the current batch.
The message to request an X or Z Report for the transactions in the current batch.
Whether the close the current batch once the report is generated.
Keeping the batch open is also known as an "X Report".
Closing the batch is also known as a "Z Report".
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive an X or Z Report for the transactions in the current batch.
The message to receive a report for the transactions in the current batch.
The paypoint associated with the batch.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The current batch number.
The 3-letter ISO 4217 currency code which amounts are specified in.
The total number of sales in the batch.
The total number of sales in the batch.
The total value of all sales in the batch in minor currency units.
The total value of all refunds in the batch in minor currency units.
A report for the current batch.
The current batch number.
The date-time at which report was generated. Represented as a date-time according to RFC 3339, section 5.6, including the relevant time zone.
A breakdown of the report by card scheme.
Items:
A report of the transactions for a specific card scheme in the batch.
The card scheme.
The total number of credit transactions.
The total value of all credit transactions in minor currency units.
The total number of debit transactions.
The total value of all credit transactions in minor currency units.
Additional properties are allowed.
Additional items are allowed.
Additional properties are allowed.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to request details of stored offline transactions.
The message to request details for offline stored transactions.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive details of stored offline transactions.
The message to receive details for offline stored transactions.
The paypoint associated the stored transactions.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The total number transactions currently stored offline.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive the status of the connected payment device.
Message confirming the status of the connected payment device.
The current status of the payment device.
The paypoint that the payment device is connected to.
The unique payment ID assigned to this paypoint by the merchant.
The payment gateway's unique terminal ID the paypoint is registered with.
Additional properties are allowed.
The connected payment device.
The serial number of the payment device.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive the status of the payment service.
Message confirming the status of the payment service.
The current status of the payment service.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to request the restart of connected payment device.
The message to request the restart of connected payment device.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive the result of the payment device restart request.
The message to receive the result of the payment device restart request.
The result of the request to restart the payment device.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.
The message to receive errors that occur while processing a request.
Message to communicate an error has occurred while processing the request.
A specific error code identifying the error scenario.
A short message describing cause of error.
Additional properties are allowed.
A UUID that links reply messages with their original request. Multiple replies may be linked to a single request.
A UUID that identifies the message. Can be used to identify duplicate messages in the event of network instability.
A unique ID that identifies the sender of the message. This should be a UUID generated by the POS application or a MAC address of the POS to maximise uniqueness.
Additional properties are allowed.