Background - we use customer profiles (Accept Customer - formally Hosted CIM) to submit payment transactions and also to be reused for recurring subscriptions.
Our code follows the directions in https://developer.authorize.net/api/reference/features/customer_profiles.html#Using_the_Accept_Custo... under the 'Using the Accept Customer Hosted Form' section, and we get a token from getHostedProfilePageRequest.
The problem is that hackers have been sitting on the hosted form to add a new profile and testing credit card numbers. They seem to have a script that keeps testing card numbers and getting declines. We have all fraud testing filters turned on, but the "Accept Customer" form does not allow us to pass in anything like customer IP address. The form stays open and allows the hacker to continually enter card numbers without any way for us to know or act. Yes we are trying all fraud dection filters, but that is not helping.
When we have asked for assistance in solving this problem, we were directed to add settings for security that were listed in the getHostedPaymentPageRequest. When attempting to add these settings, we would get the following error:
<?xml version="1.0" encoding="utf-8"?><ErrorResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00003</code><text>The element 'setting' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'setting' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'.</text></message></messages></ErrorResponse>
So the schema for getHostedProfilePageRequest would not allow extra settings to be added, and we cannot use the hosted payment form since we need the customer profile for later use.
We tried removing all of the add and edit controls from the page, but the hackers were still able to test card numbers. So they are either triggering the script on the page to show the new profile form or hijacking the transaction key and using that to open their own form. Having the token and customer profile id in the html seems to be what they are using, but they have to be there for the hosted form to work.
At this point the only way we can stop the attack is to disable all add and edit profile hosted forms from appearing on our site, which does stop them because the token is no longer in the html code, but bad because you can only place an order if you have a saved card in auth.net.
The best solution to this problem would be to have auth.net add security to the profile forms or limit the number of declines at a time, but short of that, does anyone know of a way to work around this problem?
