How can we test the CVD and expiration date for Hosted Tokenization.


I'll be using Hosted Tokenization by having the user enter the credit card number, CVD and expiration date. I read in your documentation that it will validate the format of the expiration date and CVD but are there credit card numbers I can use to test the CVD and expiration date even after I entered the correct format, to simulate an invalid expiration date and CVD?


  • With the temp token, will you be doing a card verification or a preauth / purchase? You can check our eFraud simulator table for CVD / AVS test cases ( Simulator). The hosted tokenization form doesn't allow you to enter expiry dates in the past.

    Let me know if any further questions
  • In reply to RR_Moneris:

    The plan is to use it in two places but to not handle each field individually. In one page, we will have the client enter the information and use it as a preauth/purchase and in another we would allow the client to set up the card in their profile, validate it and then use it for recurring purchases of the product.

    Would you be able to confirm that other than the format validation, as described in your documentation, will the hosted tokenization validate the CVD and the expiration date associated with the credit card number? In other words, if a client enters a credit card number but the expiration date and/or CVD number does not match the card, will it return a code like 941 or something like that?
  • In reply to PierreA:

    Hi Pierre, the hosted tokenization doesn't do any validation other than format. So there are no checks with issuer, therefor no validation of CVD / expiry. You can always do a card verification with your temp token to do your CVD check. Please note though that Card Verification is not support for Amex cards.
  • In reply to RR_Moneris:

    Thank you for the clarification. I went ahead and implemented the Card Verification for Visa & MC using both CardVerification & ResCardVerificationCC. In both cases I used the credit card numbers 4242424242424242 or 4005554444444403, mentioned on the page "Card Verification with CVD & AVS" as well as some card numbers mentioned on the page "CVD & AVS (E-Fraud) Simulator" and in both cases I get the response code 55 and the message "DECLINED * INVALID TRANSACTION=CANNOT PROCESS".

    When I use, as an example, 4242424242424242 with the same expiration date and CVD number using the PreAuth call, it gets processed with result code 27, the CVD result code 1M and the message APPROVED.

    Can you advise me of a combination of card number, expiration date and cvd I could use to test the card verification or let me know what condition would generate the DECLINED result?

  • In reply to PierreA:

    What test store ID were you using when doing the card verification? Its possible it wasn't enabled.
  • In reply to RR_Moneris:

    The previous developer had defined a store ID and apitoken but when I login into the Moneris account, I noticed that the information does not match the information in the Test Credentials section of the profile. Should I use the information in the Test Credentials section? It is possible the account might have been changed from the time of the previous developer and now. Please advise.
  • In reply to PierreA:

    Yes you can use one of the generic accounts (e.g. store 1, store3, store5, moneris). If you had a customer QA account I would need to know the business name that was used to create it... or the store ID.
  • In reply to RR_Moneris:

    Thanks for the info. I went ahead and tried the Test Credentials from our Moneris account and it worked. One lest thing, for Amex, we're using the Pre-Authorization with $0.01 and then a Pre-Authorization Completion with $0.00 to validate the card to cancel the Pre-Authorization. When we test this, I see the transactions via our Moneris account but would you be able to confirm to me if on the clients monthly statement, will they see this type of transaction?

  • In reply to PierreA:

    Hi Pierre,

    For the most part I believe preauths dont show on most of the Merchant Direct reports.

    However we don't recommend doing 0.01 preauths as a validation method. It has been known to cause issues. I suspect you want to do that with Amex because Amex is not supported for the Card Verification transaction?
  • In reply to RR_Moneris:

    Exactly, but we are confused now.

    If the preauth/capture 0.01 may cause issues and Card Verification doesn't support Amex, how do we proceed? Should we change the amount for 1.00?

    Here is the card verification solution we are trying to implement to cover all types of cards:

    1. Use CardVerification (or ResCardVerificationCC) to try to validate the card (token).
    2. If the result fails, we try a PreAuth/Capture (ResPreAuthCC/Capture) with the amount of 0.01.
    3. If the result still fails, then we return a msg indicating that the card is not valid.

    What do you think?

    As for now, with store id "monca02232", step #1 fails every time. But if we use store id "store5", step #1 passes. Can you verify if our test store has Card Verification transaction enabled?
  • In reply to RR_Moneris:

    Hello @RR_Moneris, I am not sure I understand you correctly, but your URL is now removed and I used this URL instead Simulator But there is not store5 hence the test was failed even with $10.10 leaving the CVD input empty on my form, and what should I put in the expiry? Please help!
  • In reply to pink:

    Hi, sorry for the delay on this... for the expiry, anything in the future. Why leave the CVD field empty? if testing CVD check you should pass something (just pass 123). Also the rules from the link you provided there work on most test stores.