Data Preload S

Hi,

After implement Data Preload Structure In chrome console we can still see the hpp_id (but not the token).

Is this a risk?

With Data preload does this eliminate the risk of card testing with a script?

 

Also after data preload and the return url, anything els ewe could do make the payment page more secure?

 

 

Thank you.

 

Raymond

  • Hi Raymond,

    When you say security, do you mean card testing?
  • In reply to RR_Moneris:

    Yes ,

    I'm refering to this kind of fraud
    community.moneris.com/.../card-testing-fraud-prevention

    We have implemented the following measure
    -Data preload
    -Showing user ip on payment page
    -return url

    Others ideas we are looking at are
    - Set threshold limits on the number of sales that can be submitted from the same IP address
    -decline transaction if cvd is incorrect (we don't see this feature so this would require pre-auth i think)

    Raymond
  • In reply to raymondstlouis:

    Typically open payment pages tend to be targeted more often for card testing (e.g. no registration / session tracking etc).

    If you have data preload implemented that's good. just make sure you have reset your credentials since that implementation. If hpp_id is available that's fine, as long as your hpp_key is not available to the public.

    So CVD check is good, you could also consider AVS. And yes ideally you would want our HPP to do preauth. The idea is that from the preauth response, your application checks the CVD / AVS results, and based on results present appropriate message to customer. Also based on results you can either capture the preauth, or release by doing $0 completion. This can be done manually or via your application with an API. What is very, very important is that what is presented to the customer in case of a bank decline is the exact same as what is presented if your reject it due to AVS / CVD. Because all the card tester wants to know is if its a legit card... so even if you reject it but he somehow knows it was actually approved you have given him what he wants. In the same thought, make sure that our HPP is not sending him email receipts, because we will send him receipts on approval even if you reject it.

    We also have a feature called Risk Management that will have some additional information returned with the HPP response that can be analyzed.

    Unfortunately despite all this we cant guaranty that you will not be targeted for card testing, but at least you will give them less reason to do so, and hopefully will prevent it altogether.

    Outside of this if you are still concerned you could consider some type of session management or registration required to submit a payment. You can also do IP checks, but it might not work if they have ability to send from different IPs.
  • In reply to RR_Moneris:

    Hi,

    Ok i like this answer. We will try to build that code to do the pre-Auth.
    For Avs we may also test it but only with postal code because customer often mismatch address data.

    Also i will add this for other member benefit. We also added the following measures
    -As said loggin ip (so very fast after to block problématic IP)
    -Using office 365 email rule system: alert by sms and Email when a transaction is declined.
    (this can be a sign if you start getting several alert one after the other)
    -We also did send a message to the server owner informing him that his server was use to do card testing

    Hope this will help other member

    Raymond
  • In reply to raymondstlouis:

    Just a note in regards to the AVS, you can still have customer input both street address and postal code. But when it comes to checking the results, just be a little looser, for example just reject No Matches... Because we have noticed that when passing postal code only it can increase the amount of No Matches. Let me know if you need clarification in regards to that.