Vijayashanthi,
There are two ways to accomplish this. My recommended method is to use Hosted Payments to process a Sale or Authorization, passing in address information in the TransactionSetup call. Validate AVSResponseCode and CVVResponseCode to ensure the card is valid and non-fraudulent. Then, using the TransactionID returned from Hosted Payments, create the token by processing PaymentAccountCreateWithTransID or TokenCreateWithTransID directly to the Services endpoint of Express.
Alternatively you may use Hosted Payments to process PaymentAccountCreate; however, this method does not give you an opportunity to validate AVS/CVV prior to creating the token, increasing chance of fraud. Also, this method does not apply if you're using OmniToken, as our Hosted Payments product currently cannot process TokenCreate. (If you have any questions about which method of tokenization to use, don't hesitate to ask.)
Getting lite headed and dizzy.... So basically when you do a Sale or Authorization and you use customer provided AVS/CVV data, the auth will still happen and you decide if you want to store the card based on the return data. If there is an exact match on AVS and CVV then you'd store the card. Ok fine. If there was unmatched AVS/CVV, then you would have to do a CreditCardReversal, call the customer, get the right CC info, try the auth again and again and again. All the while the customer is freaking out while you hit their card multiple time trying to get the right combination of AVS/CVV. Then they remember, "oh yeah, this card AVS was my house or my PO BOX or corporate address or..... yada yada yada". Happens ALL THE TIME.
We absolutely can not hit cards haphazardly like this.
I would first call the CreditCardAVSOnly method. They JUST fixed the documentation to reflect that this method does indeed accept CVV field as well (page 38).
If it's a match, use the PaymentAccountCreate method. They *need* to fix the documentation to reflect that this method also accepts the CVV field. (page 58).
The Worldpay developers need to give us tools to conditionally perform auth's on the Sale and Authorization methods only when we have accurate AVS/CVV data. This is 2019.
Hi Eric,
The PaymentAccountCreate call doesn't connect to the Authorization network, so the CVV data is not included within this request because we won't be able to do anything with it.
The presence of CVV in the 'CreditCardAVSOnly' call is quite new. It has historically not been an input parameter for this method. I'm unclear as to the logic of including it there.
However, it would appear to accommodate for your need - the ability to validate the card including the CVV/AVS without charging the card.
You could also consider performing the initial Auth for an amount of $0.00. This would basically be the same as the CreditCardAVSOnly call at this time.
None of these commands would require a Reversal, as you're not impacting the balance on the card.
You can proceed to call 'PaymentAccountCreateWithTransID' to generate a PASS token record based on the TransactionID from the initial $0.00 Auth or CreditCardAVSOnly call.
You would only proceed to charge the card using CreditCardSale (using the PaymentAccountID record) once you have a good match on CVV/AVS as defined by the merchants preferences.
Hopefully this helps - let us know if you have additional questions or concerns.
Regards,
Vijayashanthi,
There are two ways to accomplish this. My recommended method is to use Hosted Payments to process a Sale or Authorization, passing in address information in the TransactionSetup call. Validate AVSResponseCode and CVVResponseCode to ensure the card is valid and non-fraudulent. Then, using the TransactionID returned from Hosted Payments, create the token by processing PaymentAccountCreateWithTransID or TokenCreateWithTransID directly to the Services endpoint of Express.
Alternatively you may use Hosted Payments to process PaymentAccountCreate; however, this method does not give you an opportunity to validate AVS/CVV prior to creating the token, increasing chance of fraud. Also, this method does not apply if you're using OmniToken, as our Hosted Payments product currently cannot process TokenCreate. (If you have any questions about which method of tokenization to use, don't hesitate to ask.)