A day in the Life of a Contact Centre Card Payment

Have you ever thought about what happens once you enter your debit or credit card details into an automated system or read them out to a contact centre agent? The answer isn’t easy but it is more straightforward than many would like you to believe, so stay with me as I take you through a day in the life of a payment.

Payment Method

There are a variety of payment methods available. These may include online purchases, Chip and PIN terminals, contactless or over the phone payments with an agent but whichever method used, the underlining process of authorising the card issuer to allocate your money against that transaction in order to pay for the product or service, is roughly the same. After all, you’re not actually handing over cash, and the merchant (the company or person you’re paying) isn’t actually getting paid; they’re really just requesting an authorisation code which assures them, but crucially does not guarantee, that their merchant account will be credited with the agreed amount.

Payment Service Provider

Once card details are taken they begin their journey towards a payment gateway which is hosted by a Payment Service Provider (PSP) Encoded is a good example of a PSP, where merchants can utilise multiple payment methods from a single supplier, regardless of which company provides their merchant account. The card details are checked for errors. If these all pass, then the payment is forwarded on to the payment gateway, such as those provided by Mastercard, Barclaycard, First Data or Cardstream. These payment gateways have relationships with acquirers, which is another name for a Merchant Bank such as Streamline, Cardnet or Barclays Merchant Services (BMS). At this point the acquirer identifies the Merchant Account by way of the Merchant Identification Number (MID) which is the merchant’s account number.

Authorisation

The next important step sees the acquirer recognising your card’s long 16 digit permanent account number (PAN) as one that it deals with i.e. from a card issuer that it recognises. At this point your card’s 16 digit PAN number, the merchant’s identification (MID) number and the transaction amount are sent via the card scheme to the card issuing company. The card scheme for example could be VISA, Mastercard, AMEX or a host of others that card issuers are able to work with. Once the card issuer, Barclaycard for example, has checked that there is enough credit or balance available to fulfil the purchase an authorisation code is generated, which reserves the money against the transaction and is passed back up the chain to the payment service provider (PSP) to notify the merchant or service of the transaction outcome. Ideally the transaction has been authorised but if it’s been unsuccessful then the merchant is also informed and the transaction declined. However, even with an accepted payment no actual money has been moved yet. The payment is still held by the acquirer and hasn’t gone any further.

Final Settlement and payment

The final step is settlement for the agreed transaction; this is carried out at midnight, every night. This is when all the acquirers settle authorised payments between themselves in one large transaction to avoid multiple payment fees with the banks. At the same time reconciliation information is issued. It is the duty of each merchant to negotiate a payment term with their acquirer. This is typically measured in days (not hours) and it is finally the actual movement of money from the acquirer to the merchant for the goods sold. Charities for example might be paid within one day whereas gambling operations and furniture merchants could have to wait 5 and 30 days respectively before they get their hands on your cash. Furniture is often delivered damaged and is subject to refunds and therefore the settlement term could be longer. On the whole payment periods are determined by the merchant’s industry sector or standard industrial classification (SIC) code. Some merchants may even delay delivery of goods until settlement has been confirmed.

Failed Settlement

It is possible for an authorised transaction to fail settlement. In the event of a failed settlement, for example where a customer has reported their card lost or stolen within the same day as having made a purchase either in store, by phone or online, an authorisation code will have been generated but the payments made that day on that card will be stopped at settlement. This is to prevent fraudulent transactions from being processed after the card was reported lost or stolen. Encoded encourages its customers to do reconciliation against a settlement report and not to rely on the transaction log they receive – just in case a transaction failed to settle. It’s better to be safe than sorry.

As you can see it really is at least “a day in the life of a payment” if not longer. What may appear to be a simple case of an amount being taken from your card and a debit appearing on your statement the following month really involves far more than is at first evident.

Add to this the complications of Payment Card Industry Data Security Standard (PCI DSS) compliance and you soon realise why card accepting contact centres are wise to work with a Level 1 PCI DSS secure payment service provider(PSP) to remain compliant and maintain maximum security.

Additional Information

Rob Crutchington is a Director at Encoded

Encoded is a UK company founded in 2001 to offer affordable, pay-as-you-go IVR and payment solutions to small and large businesses. Hundreds of contact centres now rely on Encoded secure automated payments for their PCI DSS compliance requirements. Today the company’s software supports many of the UK’s leading brands including Virgin Holidays, Mercedes-Benz Finance and Hartlepool Water.

Solutions include: Virtual Terminal Payments – IVR Phone Payments – Agent Assisted Card Payments – Web Payments – Automated Recurring Payments

For additional information about Encoded please visit their Website or view their Company Profile