Improve credit card update forms: better security and end user experience

Bruce Frantzis

The current credit card update methods available to end customers have many problems. There are two methods available: Zero cost product, $1 temporary hold product (see https://support.ontraport.com/hc/en-us/articles/217881688-Collections-Recharge-Settings#how-customers-can-update-credit-cards-using-an-order-form).

Problems with both methods

The form is accessible to everyone on the internet without any authentication to restrict access. This means that the form could possibly exploited to test credit card numbers in bulk.
The end customer has to enter all their information is again (email, name, address, cc info) which is tedious and prone to data entry problems.
When the form is submitted Ontraport does not check that the user exists. If the user email does not exist then a NEW account is created. So if a user mistakenly mistypes their email or uses a different email then a new account will be created for them. Their existing account will not get updated with the CC info and the payment will fail again. This could happen multiple times with the user thinking they successfully did it (because there is no error) until the order is canceled.
When customer updates the credit card then the card number entered will update the info on all orders in collections OR all orders placed by customer. There is no option to just update the current order in collections. If a customer purchases multiple products at different times using different credit cards, to spread out the cost, and then updates one order, then all orders will start using the new credit card info and group the costs onto one card.

Problems with Zero cost method

No transaction is sent when the user updates their credit card info. A customer can enter a valid credit card number (using basic pattern matching) or a credit card that has insufficient funds. The customer thinks that they have updated the card but the payment is processed later where it fails and the customer has to go through the process again. The customer may ignore subsequent emails warning that their card was declined as they just updated it.

Problems with Temporary hold method

This is a mislabeled method, at least for Authorize.net, as what actually happens is that a transaction is placed for the amount specified and is then refunded/voided shortly afterwards. This means that it incurs the standard transaction fee imposed by the gateway. In authorize.net's case this is 30 cents + small percentage. Even though the transaction is refunded/voided the transaction fee will remain.
The real transaction, for actual amount in collections, is processed later and incurs another transaction fee.
This could be exploited to bulk test credit card number resulting in significant transaction fee charges. Ontraport support has stated that Ontrport will not be responsible for these charges. As mentioned earlier Ontraport does not check that the user exists so this could be done using any info.

Possible solutions

Send tokenized encrypted information in the URL to the update form. This can be used to secure the form from exploits and make the end user experience better. When tokenized data is passed it could be used to identify the order in collections and:

Not require the user to enter their name, email, address. Optionally provide a method to update billing address if new card is used.
Ensures that the account exists as token info can be used to find the user/order. If the token info is missing then the form will not submit transactions.
Further stop possible bulk exploits of forms by limiting update request once new CC info has been provided until the transaction is processed again.

Employ CAPTCHA entry to limit bulk update requests.

The legacy forms can do this but 'new' checkout forms do not.

Even if tokenized info is not passed then check that a user account exists using the email entered before processing trsnactions.

If not then show an error and do not process any transaction.

Provide (default option) to only update the current order in collection. Allow customer to select a check box that can optionally update all orders if they chose to do so.

Do not use refund/void transactions. Use 'Auth only' and then 'Capture' later.

This ensures that the CC is valid for the amount in collections and only incurs one transaction fee.

October 10, 2018 00:04

Please sign in to leave a comment.

3 comments

Thanks for your comments. I just have a few notes on it:

The best method is to have the customer log into a WordPress membership site and use the Customer Center to securely update the credit card. That is covered in the article in the section on Using the PilotPress Customer Center. We will be bringing similar functionality requiring log in to ONTRAPORT landing pages in the future, but I don't have an ETA on that yet. The order form method is a way to avoid having the client log into a membership site, and some people prefer it.
Some of the information on our process seems to be old; we do send transaction information for the $0 order forms; depending on the gateway we first send the $0 auth request, and if they don't honor that, then the $1 hold method (Stripe is one gateway in the latter category, as they do not honor auth requests directly). Authorize.net does charge transaction fees for validation, but my understanding is that they accept and process the $0 auth request.
The article has not been updated yet for Pages v3 that was released on Sept. 4th, but you can use reCAPTCHA on order forms now.

Frank Hagan October 10, 2018 13:42 0 votes

Hi Frank,

Thanks for your reply.

The best method is to have the customer log into a WordPress membership 
site and use the Customer Center to securely update the credit card.

We are not using a WordPress Membership site. Ontraport is the only site used for online sales. All my issues relate solely to the operation of the Ontraport site.

We do send transaction information for the $0 order forms

I will check again but AFAIK using Authorize.net CIM payment gateway this is not happening. When I last tested this a month [or so] ago the 'Zero Cost' method did not send a transaction and therefore did not validate that the card was valid with sufficient funds. We specifically chose the 'Zero Cost' method for this reason so that we were not exposed to possible form exploitation or doubled transaction fee charges.

My understanding is that they [authorize.net] accept and process the 
$0 auth request

By default Authorize.net account come pre-configured with various AVS Fraud Prevention settings one of which is a minimum charge amount that does not allow $0 transactions. This is directly configured to stop possibly significant transaction fees being generated that I mentioned in my original post. FYI, there is also another default setting that limits transactions within a certain time-frame, which is triggered by Ontraport's bulk daily processing of transactions, and must be disabled for them to go through. Authorize.net indicates that disabling these default AVS setting exposes us to greater liability if fraudulent credit card transactions take place and advise against it.

You can use reCAPTCHA on order forms now

That is great news. I will pass this on to the rest of my team and hopefully implement it shortly.

Thanks again for all your input.

Greg Brandysiewicz October 11, 2018 03:18 0 votes

Let me check specifically for Auth.net CIM with the developer in charge of that when he gets in later today! We should be doing an auth only transaction for them. Maybe there's a reason we aren't, but I thought that was the case for both our regular auth.net and the CIM integration.

I'll update this thread as things get resolved on your ticket with the developers.

Frank Hagan October 11, 2018 14:46 0 votes