lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hello,

Sorry for the late reply and thank you very much all for your responses. They are very much appreciated. My use case is not general, it is for a specific customer which requires checking expiration dates. I think you have given me good material to work with. A lot more that I would have possibly hoped for! 

My application is an IVR, so my role is to do some level of checking before sending the transaction request to the payment gateway - e.g. credit card number is between 15 to 17 digits, exp date is not a passed date, ccv is three digits. They do the heavy lifting of actually checking everything in detail. They charge my customer every time we send a request, so the less trash we send out the better. 

@Jerome, thank you for the function, I am borrowing some of your ideas! By the way, I am not sure what I am doing to send the email in HTML, I am sending it out directly from my gmail account. 

Thanks again. Have a great day.

Wilmar 


Le jeu. 18 juin 2020 à 20:03, Philippe Verdy <verdyp@gmail.com> a écrit :
All my credit cards show (in French) "Expire fin YYYY-MM" (explicitly the *end* of the indicated month). I have never seen any credit card expiring at start of that month (and renewed cards are sent to customers about 2 months before the expiration, 1 month at most, so there's a delay for activating the new card).
Note however that some credit card issuers may give additional delay, if the new credit card is still not sent, received and activated by the customer. Once the customer activates the new card, the old one replaced b y the new one is desactivated within the next 24 hours, sometimes even faster for internet transactions that can use a verification process with a transaction made by Visa or MasterCard with the issuing bank, or on cash withdrawal machines that are also connected). Credit card transactions are fast to process. And anyway almost all transactions made with a credit card must first be confirmed by the credit card issuer.
The credit card number (even with the correct checksum digit), the expiration date, the CCV code, the name of the credit card holder are not enough to confirm that a card is valid or not.
So I would not say that a credit card with an expiration month is past is invalid: In fact it may still be usable, but the indicated date MUST match (if not, Visa, MascardCard will reject the transaction as invalid). Then the transaction is on hold until the payment is confirmed by a pending status. MasterCard, and Visa will both contact the bank to confirm the transaction, the bank may provide a secure form to input some confirmation code, possibly sent by SMS or a secure mobile app that the owner must confirm, the user will then have to type that confirmation code, and then the form will be accepted and will return to the merchant that will receive a notification: "transaction confirmed" or "transaction cancelled" (when it is cancelled, Visa or MasterCard don't return the cause, the credit card may still be valid, but the user could not terminate the transaction in the limited time or could not receive the SMS or use their mobile app because they don't have their smartphone, or it is out of battery).

In summary, credit card transactions are not automatically renewable, and collecting and storing credit card numbers or info (expiry, owner, CCV) is not something that is sufficient (it worked in the past, but credit cards info were stolen on so many websites that most cards now no longer work with a transaction by transaction authorization. In addition, even if a transaction is accepted, it may be cancelled within the next 3 months if the customers signals the card being stolen (the customer gets a full refund by the bank, the merchant will have its account debited if it was credited earlier, so the merchant must keep a way to contact the customer and get enough info from him, but keeping the credit card info is useless and merchants should never store them longer than the time to process the single initial transaction: once the transaction has been confirmed, it is the transaction ID that the merchant must keep in case it gets cancelled: the merchant's bank will debit the merchant's account by providing this transaction ID which is what is needed to recover the unpaid product or service by other mean with the customer).

For recurrent payments, there's no warranty that it will work after the 1st transaction succeeded (in fact Visa or MasterCard do not offer such warranty, recurrent payments should be made only by another system). This is at least what is needed in Europe. US may have more "permissive" rules (but there's less protection in US for customers than those that exist in Europe, where all abused transactions are refundable: the customer just has to certify legally to his bank (sometimes as well to the police, but this is no longer necessary) that his credit card was lost or stolen, and the credit card will be blacklisted for all further transactions; the customer gets his money back, but no longer has a credit card, and must purchase a new one, or must pay an insurance to cover this cost and get a new one for free). It's up to merchants to pay an insurance if some of their paid transactions were cancelled, and to pay the recovery process for any unpaid billing (such recovery is generally hard and fails more than half the time).

But at least this system allows collecting statistics about abuses, and investigations on where the money was used. Banks, Visa, Mastercard, and insurance companies cooperate for these investigations and if needed they'll do the legal procedures themselves after isolating some hotspots of abusers. One example: if the "stolen or lost" card is inserted in any ATM, the user will be photographed by the machine. Many shops also have recording cameras that take photos of all those using their payment system (these are archived and usable for a few months, to allow judiciary or police procedures). But it is more difficult to track an abuser on the Internet (the IP address would reveal nothing if the IP was abused or if it was a mobile internet access on a phone with a "disposable" SIM that costs very little and whose owner's identity is not identifiable, of if this was using a public Wifi hotspot). For this reason, all internet transactions should be secured and not delayed, using the two-factor authentication procedure required by the credit card processor (use its API on your server or application!)





Le mar. 16 juin 2020 à 20:41, Coda Highland <chighland@gmail.com> a écrit :
On Mon, Jun 15, 2020 at 5:05 PM Gé Weijers <ge@weijers.org> wrote:

FYI: credit cards are valid through the last day of the month they expire in. A card expiring in YYMM == '2006' can still be used today.


You will note that almost every source on the matter says that this is "generally" true, or true for "almost all" cards. The specific day of the month is not a requirement baked into any formal credit card specification, and most finance sites instruct you to contact your issuer if it matters to you.

Cards that expire at the beginning of the month used to be more common, but with Visa and Mastercard dominating the credit card market, other providers have had a tendency to follow their lead to avoid surprising their customers.

Still: Having spent far too long dealing with ecommerce checkout pages in the past, I advise against making expiration date validation a hard error. If you want to caution the user if it looks like it might be expired, that's up to you, but let them submit it anyway!

/s/ Adam


--
--------------------------------------------------------
Wilmar Pérez