Transaction Life cycle

Quick Find

Go straight to the section you need.

1.0 Gateway Integration →

1.1 Introduction

1.2 Terminology

1.3 Integration Methods

1.4 Integration Libraries

1.5 Security and Compliance

1.6 Prerequisites

1.7 Integration Details

1.8 Authentication

1.9 Supported Actions

2.0 New Transactions →

2.1 Request Fields

2.2 Response Fields

3.0 Management Requests →

3.1 Request Fields

3.2 Response Fields

4.0 AVS/CV2 Checking →

4.1 Background

4.2 Benefits and Limitations

4.3 Request Fields

4.4 Response Fields

5.0 3-D Secure Authentication →

5.1 Background

5.2 Benefits and Limitations

5.3 Hosted Implementation

5.4 Direct Implementation

5.5 Request Fields

5.6 Response Fields

5.7 Advanced Features

11 Receipts and Notifications →

11.1 Background

11.2 Customer Email Receipts

11.3 Request Fields

11.4 Response Fields

17 Advanced Data →

17.1 Customer Request Fields

17.2 Merchant Request Fields

17.3 Supplier Request Fields

17.4 Delivery Request Fields

17.5 Receiver Request Fields

17.6 Shipping Request Fields

17.7 Device Information Fields

 

19 Gateway Wallet → 

19.1 Background

19.2 Benefits and Limitation

19.3 Hosted

19.4 Direct Implentation

19.5 Request Fields

19.6 Response Fields

 

26 Digital Wallet Transactions →

26.1 Background

26.2 Benefits and Limitations

26.3 Configuration

26.4 Hosted Implementation

26.5 Direct Implementation

26.6 Request Fields

26.7 Response Fields

26.8 Digital Wallet Tokens

Appendix

A-1 Response Codes

A-1.1 Authorisation Response Codes

A-1.2 Gateway Response Codes

A-2 AVS / CV2 Check Response Codes

A-3 3-D Secure Enrolment/Authentication Codes

A-4 3-D Secure Enrolment/Authentication Only

A-9 Duplicate Transaction Checking

A-10 Capture Delay

A-11 Card Identification

A-12 Integration Testing

12.1 Test Amounts

12.2 Test Cards

12.3 3-D Secure Testing

 

A-13 Sample Signature Calculation

A-14 Transaction Life cycle

A-14.1 Authorise, Capture and Settlement

A-14.2 Transaction States

A-15 Transaction types

A-15.1 E-commerce (ECOM)

A-15.2 Mail Order/Telephone Order (MOTO)

A-15.3 Continuous Authority (CA)

 

A-16 Payment Tokenisation

A-16.1 PREAUTH, SALE, REFUND, VERIFY requests

A-16.2 REFUND_SALE requests

A-16.3 CANCEL or CAPTURE requests

A-16.4 QUERY requests

A-16.5 SALE or REFUND Referred Authorisation requests

 

A-18 PSD2 SCA Compliance

A-18.1 Obtaining Strong Customer Authentication

A-18.2 Exemptions to Strong Customer Authentication

A-18.3 SCA Using 3-D Secure

 

A-19 Hosted Payment Page Options

A-20 Integration Libraries

A-20.1 Gateway Integration Library

A-20.2 Hosted Payment Page Library

A-20.3 Hosted Payment Fields Library

 

A-21 Example HTTP Requests

A-21.1 Hosted Integration

A-21.2 Direct Integration

A-21.3 Batch Integration

 

A-22 Example Integration Code

A-22.1 Hosted Integration

A-22.2 Direct Integration

A-22.3 Batch Integration

 

A-23 Example Library Code

A-23.1 Gateway Integration Library

A-23.2 Hosted Payment Page Library

A-23.3 Hosted Payment Fields Library

A-14 Transaction Life cycle

Each transaction received by the Gateway follows a pre-determined life cycle from receipt to completion. The stages in the life cycle are determined by the type of transaction and its success or failure at different stages in its life.

A-14.1 Authorise, Capture and Settlement

The key stages in the transaction’s life cycle can be grouped into the Authorisation, Capture and Settlement stages as follows:

 

A-14.1.1 Authorisation 

An authorisation places a hold on the transaction amount in the Cardholder’s issuing bank. No money actually changes hands yet. For example, let’s say that you are going to ship a physical product from your website. First, you authorise the amount of the transaction; then you ship the product. You only capture the transaction after the product is shipped.

 

A-14.1.2 Capture 

A capture essentially marks a transaction as ready for settlement. As soon as the product is shipped, you can capture an amount up to the amount of the authorisation. Usually, the full amount is captured. An example of a situation in which the whole amount is not captured is where the Customer ordered multiple items and one of them is unavailable.

The Gateway will normally automatically capture all authorisations as soon as they are approved, freeing up you from having to do this.

However, it is usually more desirable to delay the capture either for a period of time or indefinitely. The captureDelay field can be used for this purpose and will allow you to state the number of days to delay any automatic capture or never to automatically capture. For more details on delayed capture, refer to appendix A-9.

 

A-14.1.3 Settlement 

Within 24 hours, the Gateway will instruct your Acquirer to settle the captured transaction. The Acquirer then transfers the funds between the Cardholder’s and your accounts.

A-14.2 Transaction States

 

At any time during the transaction’s life cycle, it is in one of a number of states as follows:

 

A-14.2.1 Received 

The transaction has been received by the Gateway and stored away. This is the first stage. The Gateway will examine the transaction and pass it on to the next stage, as appropriate.

 

A-14.2.2 Approved 

The transaction has been sent to the Acquirer for authorisation and the Acquirer has approved it and is holding the Cardholder’s funds. 

This is an intermediate state and follows the received state.

 

A-14.2.3 Verified 

The transaction has been sent to the Acquirer for verification and the Acquirer has confirmed that the account is valid. 

This is a terminal state and follows the received state. The transaction will never be settled and no funds will ever be transferred.

 

 

A-14.2.4 Declined 

The transaction has been sent to the Acquirer for authorisation and the Acquirer declined it. The Acquirer will not usually give any reason for a decline and will not have held any funds. 

The transaction has now completed its life cycle and no more processing will be done on it. 

This is a terminal state and follows the received state. The transaction will never be settled and no funds will ever be transferred. The transaction responseCode will be 5 (Declined)

 

A-14.2.5 Referred 

The transaction has been sent to the Acquirer for authorisation and the Acquirer referred it for verbal approval. 

You can choose not to seek verbal approval and treat these transactions the same as a normal ‘declined’ authorisation. 

To seek verbal approval, you must phone the Acquirer and ask for an authorisation code. They will probably ask for more information about the transaction and might require you to gather other forms of identification from the Cardholder. If an authorisation code is provided, then a new transaction can be sent to the Gateway specifying the xref of this transaction and the received authorisationCode. This new request will not be sent for authorisation and will be in the ‘approved’ state ready for capture and settlement.

This is a terminal state and follows the received state. The transaction will never be settled and no funds will ever be transferred. The transaction responseCode will be 2 (Referred).

 

A-14.2.6 Reversed 

The transaction was sent to the Acquirer for authorisation and the Acquirer approved it. However, the transaction has been voided and the approval reversed. The Acquirer will have been asked to reverse any approval previously received, effectively cancelling the authorisation and returning any held funds back to the Cardholder.

The gateway will reverse an authorisation if it declines the transaction post authorisation due to any AVS/CV checking. The PREAUTH action will also automatically reverse an authorisation before return. 

This is a terminal state and follows the approved state. The transaction will never be settled and no funds will ever be transferred.

 If the transaction was reversed due to AVS/CV2 checking, then the transaction responseCode will be 5 (AVS/CV2 Declined).

 

A-14.2.7 Captured 

The transaction has been captured and the Acquirer will be asked to capture the approved held funds when the settling process next runs. The settling process usually runs each evening but the Acquirer may take up to 3 days to transfer the funds.

The capture state can either be entered automatically if the transaction requested an immediate or delayed capture; or it can be manually requested by sending a CAPTURE request. You are free to change the amount to be captured to a value less than that initially approved by issuing one or more CAPTURE commands. When captured, there is no way to un-capture a transaction. If not explicitly cancelled, it will be sent for settlement at the next opportunity.

 This is an intermediate state and follows the approved state.

 

 

A-14.2.8 Tendered 

The transaction has been sent to the Acquirer for settlement by the settling process and is awaiting confirmation that it has been accepted. 

At this point, the transaction can no longer be cancelled or re-captured.

This is an intermediate state and follows the captured state. 

 

A-14.2.9 Deferred 

The transaction could not be settled due to some temporary problem such as a communications loss. It will be attempted again the next time the settling process runs – usually first thing the next day. 

This is an intermediate state and follows the tendered state. It will normally be accompanied by a transaction response that indicates why the settlement process could not settle the transaction.

 

A-14.2.10 Accepted 

The transaction has been accepted for settlement by the Acquirer. The held funds will be transferred between the Merchant and Cardholder in due course.

The transaction has now completed its life cycle and no more processing will be done on it, unless it is subject to a rejection while the Acquirer is settling it.

This is a terminal state and follows the tendered state.

 

 

A-14.2.11 Rejected 

The transaction has been rejected for settlement by the Acquirer. The held funds will not be transferred between the Merchant and Cardholder. 

Only a few Acquirers inform the Gateway that they have rejected a transaction: they usually inform you directly. Therefore, a transaction may show as accepted even if was ultimately rejected or it may change from accepted to rejected if the Acquirer does inform the Gateway. 

The transaction has now completed its life cycle and no more processing will be done on it.

This is a terminal state and follows the tendered or accepted states. The transaction response will normally indicate the reason the transaction was rejected.

 

 

A-14.2.12 Canceled 

The transaction has been cancelled by the Merchant by sending a cancellation request to the Gateway either using the CANCEL action or via the Merchant Management System (MMS).

You can cancel any transaction that is not in a terminal state or in the ‘tendered’ state. When cancelled, any further processing that would have normally taken place will be halted. Cancelling a transaction may or may not release any funds held on the Cardholder’s card, depending on support from the Acquirer and card scheme. Note: the state is spelt American style, with a single ‘l’ as canceled

This is a terminal state and follows any non-terminal state that occurs before the transaction reaches the tendered state. 

 

A-14.2.13 Finished 

The transaction has finished and reached the end of its lifespan but did not reach one of the other terminal states. Usually this indicates that a problem has occurred with the transaction that prevents it continuing with its normal life cycle. 

This is a terminal state and can follow any other state. The transaction response will normally indicate the reason that the transaction failed.

Integrated Payments - connecting your till to your terminal

Integrated payments - connecting your EPOS till to your card terminal - enables your business to process payments faster and increase your profits.

There are many benefits to an integrated solution for almost all business types, most importantly, the removal of human error, giving you accurate reporting from all tills and terminals.

At Swipen, we offer Integrated Payments free of charge and you can use our Pay at Table or Pay at Counter software, or both if it suits your business:

Pay at Table

A software design with restaurants in mind:

Split the bill at the table

Automatic table closing

Integrated gratuity & reporting

Turn tables faster

More efficient payment

Pay at Counter

Suitable for most businesses, offering:

Faster payments

Shorter queues

Better conversion

Greater profits

COVID secure

Discover which terminal type is best for your business

Portable

Restaurants

Pubs

Cafes

Countertop

Bars

Clubs

Takeaways

Retail & Shops

Take your payments to the next level

E-Commerce Payment Solutions

With the arrival of Covid-19 into all our lives, online only payments are looking to have a bright future that’s here to stay.

At Swipen, we want to bust the myth that taking payments online is complicated, and help you
adapt to this changing world.

We offer two types of E-Commerce payment solution either directly integrated with your website or a hosted payment page.

Directly Integrated

Integrated into your own website

Completely customisable

Branded to your business

Customers stay on your website

150 currencies supported

Shopping carts

No long-term contract

Alternative payment methods, including: Alipay, Apple Pay, Google Pay, WeChatPay

Hosted Payment Page

Easy to set up

Take payments in minutes

Swipen branded

Data processed by Swipen

150 currencies supported

Shopping carts

No long-term contract

Alternative payment methods, including: Alipay, Apple Pay, Google Pay, WeChatPay

Take your payments to the next level

Virtual Terminal - Taking Payments over the Phone

Many businesses find it useful to take payments over the phone, whether you’re a travel agent
needing to take deposits, a mobile tradesperson, travelling salesperson, you have a call centre, or you don’t have a website to take payments online.

Swipen’s Virtual Terminal allows you to take card payments over the phone quickly and securely.

Our solution is a web portal that can be used on a desktop, tablet or mobile device.

Virtual Terminal Key Features

More secure than a card terminal - Completing the payment over the phone with full customer details reduces the risk of chargebacks or fraud.

Pay By Link - Send a payment link to complete the purchase or pay a balance. This is also a useful feature for customers who prefer to not give their details over the phone.

Capture Customer Details - The Virtual Terminal allows you to capture all the customer details you will need for your CRM or Booking Systems reducing the need for double inputting.

Control Permissions - Restrict user access to only certain functionality so you can control what your staff can process and see.

Take Payments anywhere - The Virtual Terminal is compatible to all devices and allows you to take payments from anywhere - office, home or on the move in a safe and secure way.

Ideal for call centres, travel agents, travelling salespeople, mobile tradespeople, restaurants for pre-bookings and parties, hotels for rooms and events, or any business that doesn’t have a website that customers can pay through.

Take your payments to the next level

Web & App Solutions - Order and Pay-at-Table Platform

With COVID regulations in force across the country, restaurants and pubs are adjusting the way they work to reduce the spread of this virus.

Swipen are also adapting to these changing times, and working with our expert partners, we can now offer order and pay-at-table platforms, allowing you to benefit from cashless and cardless payment options.

Our solutions can be either Web or App based and we provide the choice between
a ‘Simple Solution’ and a ‘Bespoke Solution’, depending on the size of your business

Bespoke Solution

The best option for individual pubs and restaurants, small chains, or if location offers a different menu:

Use your own branding

At table QR code or WiFi login

Bespoke rates and fees

Links to your EPOS till *

*Depending on the EPOS company

Simple Solution

Ideal for larger chains where every location requires exactly the same functionality and offers the same menu:

Custom built to fit your business

Customers can access the way you want

Links to both your till and kitchen

No training required

Working with Pizza Hut

Swipen have helped create a bespoke value-for money solution for Pizza Hut, and we could do the same for you.

Get in contact to find out more.

Take your payments to the next level

Tip Per Tap -Contactless Tipping System

With the dawn of cashless and touchless checkouts along with app ordering systems and pay online methods, many restaurants, bars, cafés and hotels are finding that their waiting staff are no longer able to receive cash or card tips.

Swipen has the perfect solution: the new ‘Tip Per Tap’ Contactless Tipping System

Directly Integrated

A dedicated terminal is placed in a prominent location in your restaurant.

The terminal is set to ‘donation’ and the debit amount is set at a specific figure. e.g. £2

Your happy customers simply tap their card, phone or watch against the terminal to leave a £2 tip.

They can tap multiple times to leave a larger amount

Works automatically without the need for a member of staff to supervise.

End-of-day report is separate, making it quicker and easier to share the total tips received between staff members.

How about a little Tip Per Tap

Read our blog all about our new Tip Per Tap Contactless Tipping System.

Get in contact to find out more.

Take your payments to the next level