Author: admin

This often gets neglected when setting up new payment systems. As a result your finance department often spends a considerable amount of time ensuring that all payments are reconciled.

Batches

Batches are the payment instructions to the bank. This should, therefore, be the same as the funds that are received in your bank account.

You should consider a few points, however:

1. Depending on the times’ batches are sent to acquiring banks (see the previous section) and agreement with your bank, payments will be received a number of days after they have been authorised. This is different for the various payment methods, e.g. AMEX typically has longer funding periods than VISA/MC.
2. Refunds can really throw your reconciliation out as they typically take a few days longer than authorisations to hit your bank account.

Finding your transactions

We strongly recommend you use reference fields to send information with authorisation that will help you find and reconcile payments. Preferably this is a field that is also sent to the acquirer and comes back to you in case of chargebacks.

Finding your payer and card information

If you are saving card information, you should use card and payer references that make sense to you. For example, use a unique customer number for the payer and if possible the first 6 and/or last 4 digits of the card.

Reports

You should check the reports that your processor offers as standards and see if they meet your needs. If not you should get the processor to send you daily, bespoke reports. If you require a high degree of automation these should be automatically delivered via FTP. One other solution is to use the responses you get on the individual payment request and update your database on an ongoing basis. This should enable you to run your own reports.
 

What are chargebacks?

It is a reversal or unpaid transaction in the card processing space that results in the removal of a transaction amount from the merchants’ account.

In most cases (there are exceptions), the end customer initiates the chargeback. They will ask their issuer to reverse the transaction, who will in turn instruct the acquirer to move the funds back. A merchant is then given a limited time frame to contest the chargeback and must adhere to the time frames given or he can not dispute. If the chargeback is not contested (in time) or acquirer does not accept the merchant’s contest, the acquirer will as per above, deduct the funds from the merchant’s account. In general, acquirers will err on the side of the end customer in case of disputes.

Card Schemes monitor all chargebacks that are processed and can fine or close down a merchant classified as high risk. High-risk merchants (typically >1% of transactions) can be subjected to fines for each chargeback that is received.

Note: CP merchants have chip & pin or signature which allows the merchant to sidestep liability, with CNP the merchant is always liable unless 3Dsecure is used. More about that later.

Most Common Chargeback Reasons

• The customer claims not to have authorized or does not recognize the transaction/Fraud
• The customer claims non-receipt of goods
• The goods or services were defective or not as described.
• The card has been used before the effective ‘start’ or ‘valid from’ date or after the card has expired
• A Merchant has failed to respond in time to a request for a copy of the transaction or a RFI
• The Merchant did not obtain an authorization code
• The card used in the transaction was not a valid card
• A refund was not processed or has not been credited to the same the Merchant account that was originally debited
How a Merchant can prevent chargebacks
• Use a clear DBA (Doing Business As) this is the second most common cause of chargeback after fraud
• Add the contact details to the Cardholders statement this can reduce the number of chargebacks by >60%
• Response to RFI in time with as much documentation/evidence as possible. If the window of opportunity is missed the Merchant forfeit’s their right to dispute a chargeback
• Obtain authorisation for the full amount of the sale declined transactions should not be split into smaller amounts
• Never process expired cards even though they may be authorized, likewise with Manual transactions as these cannot be contested
• Get signed proof of delivery
• Never allow a delivery to be redirected after shipment.

Transaction Authentication and Fraud Prevention

It is important to understand the difference between transaction authorisation and transaction authentication as this often creates confusion with merchants new to credit/debit card processing in a Card Not Present environment.

Transaction Authorisation is the process by which a merchant gains authorisation to debit an amount from a customer’s account from the bank that issued the customer’s credit card. This authorisation is based on the credit card number provided and the availability of funds in the customer’s account. When a transaction has been authorised, this means that authorisation has come from the customer’s bank to debit funds from account, but does not necessarily imply that the customer has authorised the transaction. The cardholder always has the right to dispute any charge that appears on their card statement, starting off the chargeback process.

In a cardholder present environment, the merchant can be reasonably assured that the customer has authorised the transaction because they are present with their card, and by having the customer sign the receipt or enter their secret pin number into a Chip & Pin terminal, they have valuable additional evidence with which to dispute any chargebacks.
Unfortunately, in a cardholder not present environment such as over the internet or phone, the situation is less secure. As such, merchants employ various transaction authentication measures to reduce their liability.

Anti -Fraud measures typically include pre-authorisation checks (know your customer, delivery address, delivery vs. payment address, 3DS, etc.), authorisation checks (CVN) and settlement checks (manual review before settlement).

A payment processor should at least offer the following:
1. Basis fraud scoring
2. 3DS
3. Card Security Code Checking – The card security code – known variously as the CVN, CV2, CVV2, CSC and a number of other acronyms – is a three or four-digit number present physically printed or embossed on the credit or debit card, but crucially, not present on the card’s magnetic strip. Because the CSC is not present on the card’s strip, it cannot be “hacked” from the card data if the card is compromised in the process known as card skimming. By providing the correct CSC with a transaction, the merchant can be reasonably assured that the customer actually holds the card in question. Some banks will decline transactions automatically on the basis of an unmatched CSC – but others do not, providing CSC checking as an advisory service only

3D Secure

3D Secure (3DS for short) is the generic name given to the authentication servcies that is developed by the card schemes. 3DS attempts to ensure that the payer is who he says he is by forcing the card holder to log onto their own bank’s website and enter a password.
In the UK 3D Secure is very widely accepted and does indeed fulfill an important role in reducing fraud. In other countries acceptance is much lower and can lead to loss of business.

It is also important to consider what your competitors do and how easy it is for a customer to switch to them.

3D Secure Scenarios and when you have liability shift

There are various outcomes, but this is the important part:

Note that Amex does NOT accept a shift in liability for the first category.
Apart from the scenarios above, there is also a category of transactions which is not completed: enrolment request was received, but actual verification never took place. In the majority of cases, this is because the customer decided to discontinue the process, for example, because they would not know their password or did not want to register for 3D Secure at the time. It is important that you will get statistics on this from your processor, broken out to as much detail as available.

Transactions are not automatically declined depending on the result. It is the choice of the merchant to either accept the risk or decline transactions. It is possible to devise a structure that would allow you to have different rules for different types of transactions, e.g. for specific countries or with higher values.

Note: It is also important that you have the ability to switch 3D Secure off altogether in case you see a sudden drop in authorisations, issues with the 3D Secure service, or big jumps in traffic.

Fraud Management Systems

If you experience a high level of fraud, it is advisable to consider implementing a specialised fraud management system.

Payment Optimisation

You should ensure you get statistics from your processor on your decline levels, broken down into as much detail as possible. Decline levels differ strongly, from 90% in general to 50% for gambling and even lower for some forms of finance products. You will also typically see higher decline levels the further away you go: highest in UK/Ireland, a bit lower in Western Europe, lower still in Eastern Europe/North America and considerably lower in Russia or Latin America.

Declines

A decline is not an error. That might sound obvious but sometimes is misinterpreted. A Payment Processor provides you with a range of error codes (available from our resource centre) for when things do go wrong. In these cases, the payment request did not get processed. Declines fall in three categories:

101 – Generic decline, which we will investigate further below.
102 – Referral; this is best described as an extra safety check by the issuer. For example, if you go on holidays to a faraway destination you are always advised to let your card issuer know; as it might otherwise require the merchant where you want to use your card to make a call before the purchase gets approved. Similarly you can call your acquirer to get an authorisation code if you receive a 102. On your website, you should treat these as 101 declines.
103 – Lost or Stolen cards. Never proceed with the order and never retry a card that received a 103 response. It will never get authorised.

101

A 101 does not always mean that the customer does not have funds in their account. You will get customers calling you to say that that they called their bank that everything is in order; there are funds, so therefore it must by you, the merchant – who is rejecting the transaction.

A Payment Processor does not reject transactions. A 101 always is a response received from the banking system, either decided by acquirer or the issuer.

Reasons

There are many. Insufficient funds are a (main) reason, but not the only one. Transactions get declined because the CVN was not or incorrectly filled in (note: an incorrect CVN will have a higher chance of rejection than a missing CVN; contrary to expectation neither will always lead to decline); incorrect expiry date (you have to submit one; again an incorrect date is no guarantee for a decline).

Issuers and acquirers can have complex decline rules. As they are managing risk, they can decline transactions for certain merchants, values, countries and or combinations of these. If you are a UK based merchant taking transactions from across the world you will find decline rates lowest in the UK, and declining the further you go (Western Europe, Eastern Europe, USA, Rest to the World).

Extra Information

A Payment Processor should provide as standard a comment with authorisation code. This information is coming directly from the issuers or acquirer and is not amended by A Payment Processor. Depending on the banks involved this information is more or less informative.
You should check if your processor offers an additional code that gives more information about the reason for the decline. It is by no means a silver bullet, but it will help identifying declines that are because of insufficient funds and will also identify a number of soft and hard declines.

Soft declines are transactions that may be successful on re-attempting. Hard declines should never be re-attempted.

Recurring Payments

If you are using recurring payments, we strongly advise you to use the same customer number for each payment relating to that customer.

It is also very important to have processes in place to keep the expiry dates up to date. Too many merchants allow the cards to expire and see their declines rates go up as a result. According to PCI, you can keep the expiry date in your system. You should contact your customer before the expiry date is reached and update it. (A Payment Processor can also provide you with reports from our tokenisation database with cards that are going to expire in the coming three months; it is also possible to update the expiry date in our database via an update message so that you do not have to create a duplicate entry).

Decline Analysis

You should periodically do a decline analysis helping you to establish decline patterns on days, times, issuing country, value, etc.

Superseding Visa’s Payment Application Best Practices (PABP), The Payment Card Industry Data Security Standard (PCI DSS) is a global set of security best practices which, when implemented correctly, will assist adhering parties in protecting their systems and help maintain the trust of their customers and clients.

There are three security standards managed by the PCI SSC:
1. The PCI PTS is the security standard that ensures hardware devices are manufactured to secure specifications and reduces the risk of tampering/misuse; devices are built with secure hardware encryption.
2. The software/firmware loaded onto the hardware must be PA-DSS compliant. The instructions sent from the software must adhere requirements outlined in the standard, encrypting data to a sufficient algorithm before transmitting the transactional data.
3. The PCI DSS is the security standard for the Cardholder Data Environment it is necessary for all entities that handle payment card/account data (cardholder and sensitive authentication data) – which is the one relevant to you.

The PCI DSS is one size fits all and not industry-specific, therefore some requirements may prove more challenging for certain organizations such as handling payment card processing within a call centre for utilities, etc. versus the requirements for online retail merchants.

The PCI DSS undergoes on-going amendments and appendages, with a new version released every three years. This is to ensure that the standards maintained and current with technological advances, security breaches, and policy shifts.

The maintenance of the standard is the responsibility of the PCI Security Standards Council. The PCI SSC was founded and is executively run by the five major global card schemes: Visa Inc. (& Europe); American Express; Discover Financial Services; MasterCard and JCB International. It was founded in 2006, is an open, international forum and hold annual conferences.

To ensure sufficient feedback is provided on upcoming amendments and appendages to the PCI standards, many of the worlds larger, international corporations are represented on the PCI SSC’s Board of Advisors. The board has representatives from the different industries involved in the Payment Card Industry including coffeehouse chain Starbucks, U.S retailer Walmart, network hardware manufacturer Cisco along with Acquirers Barclaycard and HSBC Global Payments.

PCI is enforced by card schemes via your acquirer. You will need to be annually accredited. PCI adherence and the related fines are part of the MSA agreement, so you have no option but to be PCI compliant. It applies to any entity that handles payment card /account data (cardholder and sensitive authentication data); i.e. the merchant, your gateway and acquirer.

Fines

Deloitte Analysis on Card Scheme Fines: Taking a quite modest compromise of 10,000 cards at a merchant, you could expect to have compromise fees of 5 pounds per card; investigation costs of about £30,000; an average fraud of £1,000 euros per card, card replacement costs of £20 per card; and £30 per card in chargeback fees. That comes to over £10,000,000.

1. Fines occur when merchants, service providers, and acquirers are found to be non-compliant. This is referred to as an Account Data Compromise (ADC).
2. The Card Schemes are entitled to issue fines to acquirers whose merchants are found non-compliant and have had a security breach. It is the responsibility of the acquirer to pass on these fines (with forensic investigation and remediation costs: card replacements & chargeback fees) onto the merchant. The average fine issued by Barclaycard is around £15,000. All these fees and fines are exclusive of the overall loss of revenue and inventory…
3. It is important to note, however, that on top of non-compliance fines that may be levied at any time by the Card Schemes when the non-compliance deadline has passed, compromise fines will be levied in all cases where merchants are found to be non-compliant and the subject of a security breach.
4. 40% of Merchants are non-compliant.

Cardholder Data Environment

The cardholder data environment consists of the people, processes, technologies and the transmission of cardholder data or sensitive authentication data.

People – The PCI DSS Standard requires that background checks (police/ credit/ reference) are performed on new employees. This is to mitigate the risk of internal attacks on the credit card environment and to ensure credentials are not provided to would-be fraudsters.

In addition, it is a compliance requirement that all staff handling payment card
processing/account data are educated on information security and are made aware of risks, and are able to proactively identify possible fraudulent transactions.

Processes – The methodologies used when capturing and processing cardholder data. This would include not writing down credit card numbers, ensuring staff have a unique identification. Vulnerability management programs must be created and Infrastructure staff working on the on processing interfaces should monitor and test the network for vulnerabilities. In the scenario of a security breach, structures must be in place to ensure that the loss of data is limited.

Technologies – An example of PCI Compliant technologies would be the Realex Virtual Terminal. A secure platform where merchants can take MOTO (Mail Order/ Telephone Order) transactions on a secure, compliant platform. Applications & hardware used to process transactions must be compliant with the security processes outlined in the PCI DSS

Transmission – Whilst data entry and on-site encryption may be compliant, if the data is sent via an insecure network/protocol, the exposed information would be at risk to attack. Therefore PCI DSS requires that all financial data sent/ received within the cardholder data environment is to the latest recognized standards.

Cardholder Data

Cardholder Data is the information on the payment card excluding any data that would authenticate the cardholder i.e. “digital signature”. This is the information that is “embossed” and would be recorded by a card imprint device/ ZipZap machine.

PCI DSS permits the storage of the cardholder data providing compliance requirements are met. When stored on a database, the Card Number must be encrypted upon capture and not returned to plaintext. To identify cards securely, the first six (BIN) and last four may be displayed:

xxxx xx00 0000 0000 – BIN Bank Identification Number

The BIN is used to identify the bank who issued the card. This value is important for determining the card issuer and their geographical location. An important part of fraud prevention, this would allow merchants to restrict credit card holders from outside the merchant’s country from processing on their website.

0000 0000 0000 000x – Luhn Check Digit

To reduce the incorrect entry of credit card numbers in systems where validation may not occur, PANs are subject to the Luhn check algorithm. A mathematical equation which verifies the sum of its figures against the final value/digit of the card number. Information on how the Luhn check algorithm determines this number can be found here:

http://en.wikipedia.org/wiki/Luhn_algorithm.

Sensitive Cardholder Data

Sensitive Authentication Data relates to the ‘digital signature’ of the Credit Card. These are the values used to identify that the card has been processed by the cardholder.
It cannot be recorded for any purpose, including recurring billing, tokenization, etc.
For the Card Not Present environment this would be the 3D Secure Password and the four-digit CID(AmEx), or three-digit CAV2/CVC2/CVV2.

Storing the CVV would result in PCI Compliance breach and the guilty party would be subject to fines.

Compliance

The PCI DSS is built on 12 requirements; these are surmised to six key modules:

Build and Maintain a Secure Network

Install and maintain a firewall configuration to protect cardholder data and do not use vendor-supplied defaults for system passwords and other security parameters.

Protect Cardholder Data

Protect stored cardholder data and encrypt transmission of cardholder data across open, public networks. A Payment Processor also offers a tokenisation service, which means you would only need to store tokens. We are happy to advise you on how to implement this service.

Maintain a Vulnerability Management Program

Protect all systems against malware and regularly update anti-virus software or programs and develop and maintain secure systems and applications.

Implement Strong Access Control Measures (User Credentials & Biometrics)

Restrict access to cardholder data by business need to know, identify and authenticate access to system components and restrict physical access to cardholder data.

Regularly Monitor and Test Networks

Track and monitor all access to network resources and cardholder data and regularly test security systems and processes.

Maintain an Information Security Policy

Maintain a policy that addresses information security for all personnel.

Gaining Compliance

PCI Compliance functions on a tiered structure of three levels with level one being the highest level of compliance. Each Card Scheme has slightly different determinations of what criteria determine the Merchant/Service Providers level requirements. The criteria are generally based on annual transaction volumes. This slide presentation is an example of Visa’s merchant tier structure. (source: http://www.visaeurope.com/en/businesses__retailers/payment_security/merchants.aspx)

Self-Assessment Questionnaire (SAQ)

The PCI DSS SAQ is a validation tool for merchants and service providers that are not required to undergo an on-site data security assessment per the PCI DSS Security Assessment Procedures. The purpose of the SAQ is to assist organizations in self-evaluating compliance with the PCI DSS, and you may be required to share it with your acquiring bank. Please consult your acquirer for details regarding your particular PCI DSS validation requirements.
On-Site Visits: Qualified Security Assessor (QSA)

QSAs are PCI approved companies and professionals who can assess merchant/service providers’ compliance with PCI DSS. Approved Scanning Vendor(ASV) validate PCI Compliance by performing vulnerability scans of internet-facing environments of merchants and service providers. In addition to QSAs, The PCI SSC Internal Security Assessor (ISA) Program provides large merchants, acquiring banks, and processors the opportunity to build their internal PCI Security Standards expertise and strengthen their approach to payment data security, as well as increase their efficiency in compliance with the PCI Data Security Standards.

Quarterly Network Scans: Approved Scanning Vendor (ASV)

Approved Scanning Vendors (ASVs) are organizations that validate adherence to certain DSS requirements by performing vulnerability scans of Internet-facing environments of merchants and service providers. The Council has approved more than 130 ASVs.

NEVER keep all your customer’s Card Holder Data just because you can. The best practice is that you only keep card data if there is a good business justification for it. So, don’t keep them for clients who buy a product or service, but are unlikely to buy it again (e.g. a particular course) or buy other products within a reasonable period of time (e.g. if you are selling products that have a 10-year life expectancy).

There are two main reasons for keeping customers’ Card Holder Data:
1. Repeat business; where you want to make it as easy as possible for the customer to buy again by offering a “one-click” payment.
2. Recurring business, where the customer is paying for a subscription, usage, rent, etc. on a regular basis.

If you are keeping Card Holder Data, you can opt to keep them yourselves, but this will immediately put you in the highest category of PCI compliance (I have another post dealing with PCI). There are now plenty of offerings in the market from companies that can store the cardholder data for you. Some payment service providers even offer this for free.

Note: you should ALWAYS tell the customer that you are storing the Card Holder Data. Or alternatively, allow the customer to opt-in or opt-out of their Card Holder Data being stored.

If you do decide to keep the data yourself, please note that you can NEVER store “Sensitive Cardholder Data”:

For the Card Not Present environment this would be the 3D Secure Password and the four-digit CID(AmEx), or three-digit CAV2/CVC2/CVV2/CVV.

PCI DSS permits the storage of cardholder data providing compliance requirements are met. When stored on a database, the Card Number must be encrypted upon capture and not returned to plaintext. To identify cards securely, the first six (which is the BIN which stands for Bank Identification Number) and the last four may be displayed.

Before Saving the Card

We would recommend that you process a “normal” payment on a card to check if all details are correct and only then save the card. During this process, you will also be able to carry out additional checks, such as 3D Secure. If it is not possible to process a payment you should process a “zero value” transaction or at least carry out a LUHN check, or make sure your service provider does so.

LUHN check: to reduce the incorrect entry of credit card numbers in systems where validation may not occur, PANs are subject to the Luhn check algorithm. A mathematical equation that verifies the sum of its figures against the final value/digit of the card number. Information on how the Luhn check algorithm determines this number can be found here: http://en.wikipedia.org/wiki/Luhn_algorithm.

Customer Record

In the customer record, you need to save the following additional data (note that some service providers might require other data to be stored as well):
1. Expiry Date. This does not have to be encrypted.
2. A reference, often called a token. This is the string that you will use to get access to the Card Number, but can be displayed.

We would recommend that you create a token that includes the customer number (provided it is unique) and first 6 and last 4. This makes it easily searchable and can be of help when dealing with a customer on the phone.

Of course, it is different if you do not store the card data yourself. Service providers mostly provide you with a token of their own creation, which is often meaningless. You should still however ensure that your service provider gives you back the useful information as per above (expiry date, first 6 and last 4 digits). In this instance, you will need a third field in your record to store the latter.

Note: if you allow customers to stored multiple cards, you will obviously need to store this data for each of the cards separately and have some sort of index.

One-click payment

This will require you to provide your customers with a safe and secure account into which they can log in online. Within the account, the customer will as normal create a shopping cart of some form. Before the “Buy Now” button (or similar) you should give the customer the option to go to your normal payment page OR pay with a stored card. If the customer opts for this, you can skip the payment page as you can simply use the token saved in the customer record to “collect” the Card Holder data, either stored in your own database or with your service provider.

As you cannot store CVV data, you might opt to ask the customer to fill in the CVV in a separate field, which you then of course have to send in with the payment information. (Check if your provider supports this and ensure the data is not kept).

We would recommend a number of things (note: some providers will offer some of these services in addition to keeping the tokens so you might not need to build it yourself)
1. As you should keep the expiry date, you should build a logic that will disable the one-click-payment option and display a message to the client that they should update their Card Holder Data first (see below).
2. You should display the first 6 and last 4 OR last 4 digits of the card with the option to use a stored card, as this means the customer will know what card is being used. If you allow multiple cards to be used, you should display each separately.
3. You should also display a option to change or add a card if they want to use another card.

If the customer needs to edit, change or add Card Holder Data, you should bring the customer to a new screen where you would again show the first 6 and last 4 OR last 4 digits, and the expiry date of each card held. It should be possible for the customer to delete a card, add a card (which means saving a card without a purchase), or editing the expiry date (most providers offer an API to send the token with a new expiry date). Once finished you should ensure there is a button that returns the customer to the purchase, and that closing the window will do the same. The information here will of course have to be refreshed to ensure the new data is displayed.

You might want to ask a customer to go through the 3Dsecure process. Again, if using a service provider for your tokens, you should check if your provider supports the combination of a token and 3DS. As this takes away the convenience of one-click payments, we feel however you should only do so if you have a very good reason to do so. For example, if the customer just added a new card or if the goods or services purchased are of great value.

Recurring Payments

Often all payments done with a token are referred to as “recurring payments”. This is not correct. Only payments that are done on a regular, fixed interval (weekly, monthly, etc.) are recurring payments. Some acquirers also mandate that the amount should be the same.
You should talk to your acquirer, as some acquirers often specific MIDs (accounts) for recurring payments. These often offer lower rates. However, some require specific information to be added to your messaging which means additional coding. A benefit is however that such a MID does not look for a CVV code (which on a standard MID might lead to the transaction being declined).

If a recurring payment is set up as part of a purchase process, you will again simply process the payment and save the card used. This will also allow you to process the CVV and if you wish bring the customer through a 3DS check.

If however the recurring payment is set up as part of a registration process, you should provide your customers with a safe and secure account into which they can log in online. When it comes to setting up the payment information, you could use the same screen as mentioned above for deleting, editing, and adding Card Holder Data. And remember the LUHN check!

When it comes to payment, you now do not require customer involvement. You can simply “stream” payment requests into your payment service provider, using the tokens to “collect” the cardholder data, either internally or with the provider. This does however require a scheduler and a corresponding interface to set up schedules and amount. Many service providers will offer these, but they do not always offer the type of schedule that you require, so you should do some detailed checks!

Schedules should always have a start date, an interval, and an end date. Intervals can be weekly, monthly, but also a particular day in the month, a first or last day (e.g. Friday) in the month, etc. It can get tricky if you have to maintain different schedules for different customer groups.

It would also be advisable that you have some reference in the payment record in your system that shows that that payment was done as part of a particular batch, for reporting reasons.
It would also be advisable to have a retry mechanism. I.e. failed* transactions should be resubmitted for payment after x days and again after y days (if the first retry was also unsuccessful). This does of course require you to keep a reference in your system that tracks the number of times a particular payment has been tried. You should NEVER try more than three times in total. Once tried three times, you could consider sending an automatic email to the customer advising them of the failure to pay and advising them to make payment manually. This could of course also be used as an alternative to a retry mechanism, where the email would have to be sent after the first failure.

*Note: you should not retry ALL failed transactions. Depending on the failure message, some will never be successful and should not be retried. Depending on your service provider and acquirer, this information can be very generic or very granular.

Expiring cards

I would recommend that you set up a logic that will automatically warn the customer that their expiry date is coming up and invite them to log in to their account and update their Card Data.

If Cards are expired, you should have the ability to run a report containing all expired cards and the relevant customer data, so that they can be contacted manually.