Example HTTP Requests

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 Secure Authentication Data

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 SCA Soft-Declines

A-18.3 Exemptions to Strong Customer Authentication

A-18.4 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-21 Example HTTP Requests

A-21.1 Hosted Integration

A-21.1.1 Transaction Request HTTP Headers 

The following HTTP headers are sent for transaction request:

HTTP Header
content-type
Mandatory
Y
Description
Content type of the request. This must be ‘application/x-www-form-urlencoded’, A charset parameter is optional and any non UTF-8 request will be converted to UTF-8.

A-21.1.2 Transaction Response HTTP Headers

The following HTTP headers are received for a transaction response:

HTTP Header
Status
Description
HTTP status header. Possible value are:

200 – Transaction request processed

500 – Internal Server Error

503 – Service Temporarily Unavailable

HTTP Header
content-type
Description
Content type of the response. This will be ‘application/x-www-form-urlencoded’

A-21.1.3 Submission Example 

 

The following shows an example of a transaction request:

 

  1. HTTP/1.1 200 OK 
  2. POST /hosted/ HTTP/1.1 
  3. Host: gateway.swipen.com 
  4. Accept: */* 
  5. Content-Length: 314 
  6. Content-Type: application/x-www-form-urlencoded 
  8. merchantID=100001&action=SALE&type=1&currencyCode=826&countryCode=826&amount=680&transactionUnique=5de651c7c5379&orderRef=Test+Transaction&redirectURL=https%3A%2F%2Fmyshop.com&signature=ba12b0766a3412782448f154be15e8f61eea390387b1b23d4688c82c9f28f81df593de5890426546cca365943cc7b5c4897c9721b663a0e17680e1e796f1ad55 

 

The following shows an example of a transaction response:

 

  1. HTTP/1.1 200 OK 
  2. Date: Tue, 01 Jan 2019 09:30:45 GMT 
  3. Server: Apache/2.4.23 (Win64) OpenSSL/1.0.2k-fips PHP/5.4.12 
  4. Vary: Host 
  5. X-Powered-By: PHP/5.4.12 
  6. Expires: Thu, 19 Nov 1981 08:52:00 GMT 
  7. Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
  8. Pragma: no-cache 
  9. Content-Length: 4129 
  10. Content-Type: text/html 
  12. <!DOCTYPE html> 
  13. <html> 
  14. — Hosted Payment Page HTML Removed — 

15. </html>

A-21.2 Direct Integration

The following HTTP headers are sent for transaction request:

HTTP Header
content-type
Mandatory
Y
Description
Content type of the request. This must be ‘application/x-www-form-urlencoded’, A charset parameter is optional and any none UTF-8 request will be converted to UTF-8.

A-21.1.2 Transaction Response HTTP Headers

The following HTTP headers are received for a transaction response:

HTTP Header
Status
Description
HTTP status header. Possible value are:

200 – Hosted Payment Form returned

500 – Internal Server Error

503 – Service Temporarily Unavailable

HTTP Header
content-type
Description
Content type of the response. This will be ‘text/html’

A-21.2.3 Submission Example

 

The following shows an example of a transaction request:

 

  1. POST /direct/ HTTP/1.1 
  2. Host: gateway.swipen.com 
  3. Accept: */* 
  4. Content-Length: 397 
  5. Content-Type: application/x-www-form-urlencoded 

7.merchantID=100001&action=SALE&type=1&currencyCode=826&countryCode=826&amount=680&transactionUnique=5de65b552499e&orderRef=Test+Transaction&cardNumber=4929+4212+3460+0821&cardCVV=356&cardExpiryDate=1219&threeDSRequired=N&avscv2CheckRequired=N&duplicateDelay=0&signature=06b01e06c8fc761943d676d5f3aa2e9264758fed72e7bcb058a2a35cf23e8e45403099537bb0363054d6bc8ea951ce1ad86e582dbf0b435855b9c97507fcf844 

 

The following shows an example of a transaction response:

 

  1. HTTP/1.1 200 OK 
  2. Date: Tue, 01 Jan 2019 09:30:45 GMT 
  3. Server: Apache/2.4.23 (Win64) OpenSSL/1.0.2k-fips PHP/5.4.12 
  4. Vary: Host 
  5. X-Powered-By: PHP/5.4.12 
  6. Content-Length: 2449 
  7. Content-Type: text/html 

9.merchantID=100001&threeDSEnabled=Y&avscv2CheckEnabled=Y&riskCheckEnabled=N&caEnabled=Y&rtsEnabled=Y&cftEnabled=Y&threeDSCheckPref=not+known%2Cnot+checked%2Cauthenticated%2Cattempted+authentication&cv2CheckPref=matched&addressCheckPref=not+known%2Cnot+checked%2Cmatched%2Cpartially+matched&postcodeCheckPref=not+known%2Cnot+checked%2Cmatched%2Cpartially+matched&cardCVVMandatory=Y&riskCheckPref=not+known%3Dfinished%2Cnot+checked%3Ddecline2%2Capprove%3Dcontinue%2Cdecline%3Ddecline1%2Creview%3Ddecline2%2Cescalate%3Dfinished&notifyEmail=an.operator%40merchant.com&customerReceiptsRequired=Y&merchantCategoryCode=6013&surchargeEnabled=Y&surchargeRequired=N&surchargeRules%5B0%5D%5BcardType%5D=CC&surchargeRules%5B0%5D%5Bsurcharge%5D=10.1235&surchargeRules%5B1%5D%5BcardType%5D=CC&surchargeRules%5B1%5D%5Bcurrency%5D=GBP&surchargeRules%5B1%5D%5Bsurcharge%5D=2.5000&surchargeRules%5B2%5D%5BcardType%5D=VC&surchargeRules%5B2%5D%5Bsurcharge%5D=3.5000&surchargeRules%5B3%5D%5BcardType%5D=VC&surchargeRules%5B3%5D%5Bcurrency%5D=GBP&surchargeRules%5B3%5D%5Bsurcharge%5D=4.5000&surchargeRules%5B4%5D%5BcardType%5D=DD&surchargeRules%5B4%5D%5Bsurcharge%5D=5.5000&action=SALE&type=1¤cyCode=826&countryCode=826&amount=680&transactionUnique=5de65b552499e&orderRef=Test+Transaction&cardExpiryDate=1219&threeDSRequired=N&avscv2CheckRequired=N&duplicateDelay=0&requestID=5de65b562496f&responseCode=0&responseMessage=AUTHCODE%3A347414&state=captured&requestMerchantID=100001&processMerchantID=100001&paymentMethod=card&cardType=Visa+Credit&cardTypeCode=VC&cardScheme=Visa+&cardSchemeCode=VC&cardIssuer=BARCLAYS+BANK+PLC&cardIssuerCountry=United+Kingdom&cardIssuerCountryCode=GBR&cardFlags=8323072&cardNumberMask=492942%2A%2A%2A%2A%2A%2A0821&cardNumberValid=Y&xref=19120312NG55CM51QH35JRL&cardExpiryMonth=12&cardExpiryYear=19&authorisationCode=347414&transactionID=10018201&responseStatus=0×tamp=2019-12-03+12%3A55%3A52&amountApproved=680&amountReceived=680&amountRetained=680&avscv2ResponseCode=244100&avscv2ResponseMessage=SECURITY+CODE+MATCH+ONLY&avscv2AuthEntity=merchant+host&cv2Check=matched&addressCheck=not+matched&postcodeCheck=not+matched&notifyEmailResponseCode=0&notifyEmailResponseMessage=Email+successfully+queued&vcsResponseCode=0&vcsResponseMessage=Success+-+no+velocity+check+rules+applied&currencyExponent=2&signature=e5c65e5d0340e0ec0de8782affcb6caba2e4d202a6873a1677ddbf6415cb1dd52cc597e43c758b233afd121367d300a57d0faade7abf6b4b88a1a1b974e55d33 

A-21.3 Batch Integration

A-21.3.1 Submission Request HTTP Headers

The following HTTP headers are sent for batch submission request:

HTTP Header
content-type
Mandatory?
Y
Description
Content type of the batch request. This must be ‘multipart/mixed’ and contain a boundary parameter to separate each transaction request. A charset parameter is optional and any none UTF-8 request will be converted to UTF-8.
HTTP Header
content-encoding
Mandatory?
N
Description
Optional content encoding applied to the request. The value should be a comma separated list of one or more: x-gzip, gzip, base64.
HTTP Header
authorization
Mandatory?
N
Description
Optional username and password to authenticate the submitter

The following HTTP headers are sent on each individual part request:

HTTP Header
content-type
Description
Content type of the individual request. This must be ‘application/x-www-form-urlencoded’, A charset parameter is optional and any none UTF-8 request will be converted to UTF-8.
HTTP Header
content-encoding
Description
Optional content encoding applied to the request. The value should be a comma separated list of one or more: x-gzip, gzip, base64.
HTTP Header
content-id
Description
Optional identifier for each individual transaction with the batch. The Gateway will return this identifier in the submission response. If not sent, the Gateway will generate a unique identifier for each transaction.

A-21.3.2 Submission Response HTTP Headers

The following HTTP headers are received for batch submission response:

HTTP header
status
Description
HTTP status header. Possible value are:

200 – Batch submission status response ok

201 – Batch submission received and stored

400 – Batch submission invalid

401 – Unauthorised (none or incorrect credentials)

405 – HTTP method was not POST/PUT or GET

500 – Internal Gateway error

HTTP header
location
Description
URL to use to monitor the status of the batch. A unique batch reference number will be provided in the URL in the format: XXXX-XXXX-XXXX-XXXX (eg 1A23-B4C5-DEF6-G7HI). This reference number is used to request information about the status of a batch via HTTP GET requests to the URL endpoint as outlined in section 1.3.3.
HTTP header
x-p3-token
Description
If user authentication was sent in the initial request, this header will contain a token that can be used for future requests for the status of the batch instead of having to use a username/password.
HTTP header
content-type
Description
Content type of the HTTP batch request. This will be ‘multipart/mixed’ and contain a boundary parameter to separate each transaction request.

The following HTTP headers are received on each individual part response:

HTTP header
content-type
Description
Content type of the individual request. This will be ‘application/x-www-form-urlencoded’, A charset parameter is optional and any none UTF-8 request will be converted to UTF-8.
HTTP header
content-id
Description
The content ID sent in the initial request as outlined in A-21.3.1. If no content-id header was sent, the Gateway will return a unique content ID per transaction.
HTTP header
x-transaction-id
Description
The Gateway transaction ID. This will be empty if the transaction is currently pending in this stage.
HTTP header
x-transaction-response
Description
A message containing the current status of the transaction. Possible value are:

skipped – insufficient permissions to view transaction

pending – queued for processing

success – (Response Message)

failure – (Response Message)

A-21.3.3 Status Request HTTP Headers

 The following HTTP headers are used during a batch status request:

HTTP Header
authorization
Mandatory
Y
Description
Mandatory username and password to authenticate the submitter

A-21.3.4 Status Response HTTP Headers

 

The batch status response is identical to the submission status response as documented in section A-21.3.2. 

 

A-21.3.5 Submission Example 

 

The following shows an example of a batch submission request:

 

  1. PUT /batch/?validate=0 HTTP/1.1 
  2. Authorization: Basic bmljay50dXJuZXI6dGVzdGluZzI= 
  3. Host: gateway.swipen.com 
  4. Accept: */* 
  5. Content-type: multipart/mixed; charset=UTF-8; boundary=5de63a42507a9 
  6. Content-length: 1404 
  8. –5de63a42507a9 
  9. Content-Id: TX5de63a42507ac 
  10. Content-Type: application/x-www-form-urlencoded; charset=UTF-8 

12.merchantID=100001&action=SALE&type=1&currencyCode=826&countryCode=826&amount=680&transactionUnique=5de63a42507ac&orderRef=Test+Transaction&cardNumber=4929+4212+3460+0821&cardExpiryDate=1219&duplicateDelay=0&signature=3cd686fdd40449ef33534baa62732c95fc127ff591fae3b5b611ccb38573ad921d199396e27cffd14faa4f46df8dde310252920fd1b33607b029b9b6ff669e2b 

  2. –5de63a42507a9 
  3. Content-Id: TX5de63a42af062 
  4. Content-Type: application/x-www-form-urlencoded; charset=UTF-8 

18.merchantID=100001&action=SALE&type=1&currencyCode=826&countryCode=826&amount=681&transactionUnique=5de63a42af062&orderRef=Test+Transaction&cardNumber=4929+4212+3460+0821&cardExpiryDate=1219&duplicateDelay=0&signature=55f411d40954be7f7089e84fe489438f09fc1b37c0964e46b0fab8bdcb44e13ed3ea11b9deb9da89a6d7b45133709a126bd3581f6329bf888b83231184597231 

  2. –5de63a42507a9 
  3. Content-Id: TX5de63a42ca9cd 
  4. Content-Type: application/x-www-form-urlencoded; charset=UTF-8 

24.merchantID=100001&action=SALE&type=1&currencyCode=826&countryCode=826&amount=682&transactionUnique=5de63a42ca9cd&orderRef=Test+Transaction&cardNumber=4929+4212+3460+0821&cardExpiryDate=1219&duplicateDelay=0&signature=c296266cb9bc8082957c700da9651d98add176dd8bd62eb3b7098566c7d8e23a3426b776de815e99149c6681978b1addedac762339563732d8a449b6cca3a3c2 

  2. –5de63a42507a9– 

 

The following shows an example of a batch submission response: 

 

  1. HTTP/1.1 201 Created 
  2. Date: Tue, 01 Jan 2019 09:30:45 GMT 
  3. Server: Apache/2.4.23 (Win64) OpenSSL/1.0.2k-fips PHP/5.4.12 
  4. X-Powered-By: PHP/5.4.12 
  5. x-p3-token: YTo1OntzOjc6InZlcnNpb24iO3M6ODoiUDNUSy8yLjAiO3M6NzoicHVycG9zZSI7czo0OiJhdXRoIjtzOjc6ImNyZWF0b3IiO3M6NToiQkFUQ0giO3M6NzoiY3JlYXRlZCI7aToxNTc1MzY5Mjg1O3M6NzoiZXhwaXJlcyI7aToxNTc1MzcyODg1O30.czozOiI2MjkiOw.zdfxxXYtC2Wc4yyk-lEos-wZ99pEJtPGYpXR4KCiWW_56nmOysarOaMucrWPIt-NzwFzgq3-7u4Ud6uYkQcWBQ 
  6. Location: /batch/2D6D-AC2C-BF55-2A8C 
  7. Content-disposition: attachment; filename=”batch-2D6D-AC2C-BF55-2A8C” 
  8. Content-Length: 1857 
  9. Content-Type: multipart/mixed; charset=UTF-8; boundary=5de63a5c1a071 
  11. Transaction ‘TX5de63a42507ac’ – pending – queued for processing 
  12. Transaction ‘TX5de63a42af062’ – pending – queued for processing 
  13. Transaction ‘TX5de63a42ca9cd’ – pending – queued for processing 
  15. –5de63a5c1a071 
  16. Content-Id: TX5de63a42507ac 
  17. Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
  18. X-Transaction-ID: 
  19. X-Transaction-Response: pending – queued for processing 

21.merchantID=100001&action=SALE&type=1¤cyCode=826&countryCode=826&amount=680&transactionUnique=5de63a42507ac&orderRef=Test+Transaction&cardNumber=492942%2A%2A%2A%2A%2A%2A0821&cardExpiryDate=1219&duplicateDelay=0&signature=0384bbf6ca0fc153e1e27a0cfc51f3b1cd1c2cff7a49aa4e9439bba38262183e9ac7d156f218eba1ef8d04f9e6a7fa6fbc9c2b3ab990c70e06dc7c6923e5b27b 

  2. –5de63a5c1a071 
  3. Content-Id: TX5de63a42af062 
  4. Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
  5. X-Transaction-ID: 
  6. X-Transaction-Response: pending – queued for processing 

29.merchantID=100001&action=SALE&type=1¤cyCode=826&countryCode=826&amount=681&transactionUnique=5de63a42af062&orderRef=Test+Transaction&cardNumber=492942%2A%2A%2A%2A%2A%2A0821&cardExpiryDate=1219&duplicateDelay=0&signature=1e13e23c2b90a30f4403d604ac20302b5504b886b0b5c9ace0764fc8d966d120f5a1beca975805292780c22953b4e6ca71f67f499804f19d2718518463a598c4 

  2. –5de63a5c1a071 
  3. Content-Id: TX5de63a42ca9cd 
  4. Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
  5. X-Transaction-ID: 
  6. X-Transaction-Response: pending – queued for processing 

37.merchantID=100001&action=SALE&type=1¤cyCode=826&countryCode=826&amount=682&transactionUnique=5de63a42ca9cd&orderRef=Test+Transaction&cardNumber=492942%2A%2A%2A%2A%2A%2A0821&cardExpiryDate=1219&duplicateDelay=0&signature=c456aa211f8e3e568a40051bfd38406be02566fcd72d3bb1547f4d43e75db1d069eaa4158aa035337cac084633df945a13471db6b1a3fcd6c0749626d9bc0044 

  2. –5de63a5c1a071– 

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

get in touch today

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

get in touch today

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

get in touch today

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

get in touch today

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

get in touch today