cancel
Showing results for 
Search instead for 
Did you mean: 

Hosted form being hijacked to send 1000s of attempts to add card to profile.

I use the Customer Information Manager (CIM) to hold all of our customer credit card information.  I use a Hosted Form (https://developer.authorize.net/api/reference/features/customer_profiles.html) for adding and editing credit cards.

 

The problem is someone is programatically using this to send 1000s of attempts at adding a credit card.  This is a common problem which is referred to as "Card Testing".

 

I was instructed to turn on the Fraud Detection Suite to help with this.  I can see that I can limit the number of transactions per hour and day to help prevent this in the future. I have done that.

 

The Fraud Detection suite also offers the ability to limit activity based on IP address. I'd like to use this as it would give me more control over who to approve and not approve.

 

The problem is, there doesn't appear to be anyway to pass the IP address as part of the Hosted Form process.  The hosted form process happens in two steps, first you request a hosted form token using the getHostedProfilePageRequest. There is nothing in the schema (https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd) that allows the passing of the IP address. The only allowed settings are:

 

 

hostedPaymentIFrameCommunicatorUrl, hostedPaymentButtonOptions, hostedPaymentReturnOptions, hostedPaymentOrderOptions, hostedPaymentPaymentOptions, hostedPaymentBillingAddressOptions, hostedPaymentShippingAddressOptions, hostedPaymentSecurityOptions, hostedPaymentCustomerOptions, hostedPaymentStyleOptions

 

The token is then used as a hidden value in a form that is submitted to either create or edit a payment profile and to get a hosted form in an iframe.

 

I don't see of any method of passing in an IP address as part of this process.  Am I missing something or does anyone have a suggestion of how to add an IP address as part of the process?

 

My guess is there is no support for passing an IP address in this situation and that I'll have to use the Daily and Hourly velocity filters for limiting these fraudulant requests.

pberce
Contributor
5 REPLIES 5
@pberce

The ip filters work without you having to pass the IP. I would suggest firewall, DDOS protection, and implementing captcha on your registration process. Those combined should get rid of this problem.
You can also log server side and block the profiles in question. If users are programmatically adding cards they are not good users. I would deactivate those profiles. If they are legit users who were hacked, send them a notification.
Renaissance
All Star
And my captcha, I mean both traditional and also any custom built “you are human” filter.

Renaissance,  Thank you for the reply. 

 

I was under the impression that I the IP address had to be passed as part of the payload when requesting a token for the Hosted Form for adding a credit card via the Customer Information Manager for it to work.  It doesn't support this.  The reason I was thinking this is when I talked with support they said that there was no IP address associated with any of the fraudulant attempts at adding a credit card.

 

I've turned on the regional IP address filtering to block all but US attempts.  We don almost exclusively within the US so this shouldn't be a problem.  It will notify me if we have an attempt outside of that region.

 

As for CAPTCHA.  Again, the Hosted Form for adding and editing a credit card does not support CAPTCHA.  I know I could add it on the page where the form is invoked, the problem with that is the form is already embedded on the page.  So I may need to rethink that process.

 

As for restricting users.  This was a brand new user so there really isn't anything to do there other than deleting their account.  The problem is they could just create another.

@pberce

You yourself could capture the IP. The fraud filter in the interface is for transactions and maybe not adding cards. What I was saying is that the CIM, I believe, has an unique user id. You could change your login process to be that the customer has to create an account with you first. Then you get captcha there. At this point it’s hard to go back though.

Ideally in case you are doing month-to-month ordinary costs, Automated Recuring billing have to be the better answer to use that is designed for those form of purposes here, and you may no longer ought to worry about the fraud filters.

alres333
Member