If you run a transaction in our gateway and enter a date in the past for the credit card expiration date, you may be surprised to discover that we don't validate it. We run the transaction knowing that the card is expired. Why do we do this? The short answer is that financial institutions will still approve transactions with expired expiration dates.
To quantify the advantage of allowing expired expiration dates to be sent, we recently analyzed a large transaction data set and found that roughly 1.4% of all attempted transactions were processed with expired cards. Of these, 34% were successful. For a merchant processing $250,000 per month, that's an additional $1,190 in revenue. (Note: we're only referencing expired dates in this analysis, not incorrect dates.)
Another interesting pattern we uncovered was that the month of January consistently made up the majority of expired months. Within one data set of expired expiration dates, we noticed that January of that year was sent for 85% of the transactions. We think this might be happening because January of the current year is often the default expiration month for a checkout page. It appears as if a number of customers are not changing the default setting for expiration date when submitting transactions. While some of these transactions are successful, the majority fail, resulting in lost revenue to the merchant. We encourage businesses to take a look at their checkout process to ensure that a default value isn't being consistently passed through on transactions. One specific suggestion is to replace a dropdown input for the expiration date with a text field.
Comments: 0 | Post a CommentThe payment processing industry is a total mess. The Braintree folks are straight shooters. Save yourself serious pain and go straight to them.
We love this quote. We love that Rob appreciated what we do and how we do it. It's true, the payment processing industry is a total mess. So with that in mind, we thought we would create a checklist you can use when evaluating prospective providers - so you don't get duped.
We've released a new version of the Braintree client libraries today and we wanted to give you a brief update on the changes we've made. Please note that the older versions of the client libraries will still be supported. However we do recommend you upgrade.
We've changed the behavior of a couple methods in a backwards incompatible way, so please review these release notes before upgrading
We received several questions about how to determine if a new transaction was actually authorized. We've updated the client libraries to make this more clear by changing the behavior of the result object that is returned from creating a transaction. Now, the success method will return false if the transaction is declined or gateway rejected. However, there won't be any validation errors like there usually are when success returns false. Instead, the error result contains the declined or rejected transaction for further inspection.
Updated Workflow Examples: Ruby | Python | PHP | Java | .NET
Previously, when traversing a paginated collection it was necessary to explicitly request new pages as needed. We've simplified this in the latest release by transparently handling paging while the collection is traversed.
Examples: Ruby | Python | PHP | Java | .NET
Hope the new release is helpful!
Thanks,
The Braintree Dev Team
© 2010 Braintree Payment Solutions. All rights reserved. Braintree is a registered ISO/MSP of Wells Fargo Bank, N.A., Walnut Creek, CA
