Question: AVS / Preventing Fraud

[mikestecker]

Is there a way to prevent fraud or is that done on the backend? I'm new to this process so I'm still understanding how it all works.

Is this module essentially just running a "pre-authorization" and the rest of it gets sent to the server for final charge? Is that how the process works?

Should I have the user add their card, store the opaqueData object returned and post both the opaqueData and address information to the server for processing with Authorize.net's API, then have it do AVS that way?

Apologies in advance, but I'm trying to wrap my head around the whole process.

Thanks!

[j-em]

Hello!

Since react-authorize-net is merely a thin React layer on top of Accept.js, a lot of its documentation applies here too.

Typical workflow

Frontend

1) Collect payment information 2) Request a payment nonce by sending payment information to Authorize.Net 3) Pass the payment nonce to your server for processing

Backend

4) Pass the payment nonce to Authorize.Net, i.e actually process the transaction.

How does AVS fits in this

There are two ways you can have an AVS check for your transactions.

1) Pass a zip code along when requesting the payment nonce on your frontend.

2) Pass the payment nonce along with the zip code to your backend, and then pass both to Authorize.Net when processing the transaction.

Either way should make their system do an AVS check when it processes your transaction.

I hope this helps - don't hesitate if you have any other questions.

[mikestecker]

@j-em Thanks for being patient with me and giving me this info.

So in regards to Pass a zip code along when requesting the payment nonce on your frontend., would this be possible with your module or would I need to fork the code and make some changes on my end? Also, looks like you can also pass not only the zip but also fullName from what I see on the docs?

I'm ultimately trying to achieve a multi-step form:

1. User selects a membership plan, the plan ID and price is stored in state
2. Next screen user inputs billing details such as name/address, all stored in state
3. Next screen (could be combined with above) user inputs card with this module, runs pre-auth on card, gets back payment opaqueData.dataDescriptor and opaqueData.dataValue, then store these in state as well (I eventually also want to work in some sort of coupon function as well so this might adjust my screens, but you get the idea...)
4. Confirmation screen, user reviews all final details, given chance to go back and edit before final submission to run GraphQL mutation (I'm running a Apollo/Prisma setup), pushing everything in the state to the backend, which then charges the card with Authorize.net, creates invoice and finally upgrades the user's membership account.
5. Return success screen with invoice details

Is it best to run AVS on the frontend? I figure this might alleviate more hits to the backend in case of failures? I'll probably pass along zip/name on the backend anyway as a second check, but I'm thinking I should do it on the frontend as well?

[j-em]

Currently react-authorize-net doesn't have any knowledge about which zip code is associated with a given transaction. It only knows about the card number, the card code and the expiration date.

This means passing the zip code when requesting the payment nonce is a little difficult with the library as it is right now.

I think that's absolutely something that the library should support though. I'll try to push a fix for this asap.

In the meanwhile, if you feel like forking the project and sending a PR for this, I would be more than happy to merge it.

I am not sure how doing an AVS check on the frontend would look like. The documented behavior by Authorize.Net really revolves around your frontend getting a payment nonce and your backend processing this payment nonce by passing it to Authorize.Net to create a transaction.

Don't hesitate if you need any clarifications about anything.

[mikestecker]

Thanks for the quick reply. I'll leave the zip code addition to you, I'm not the most qualified at this point in my skill level to make the addition.

Looking at my multi-step form I'm trying to achieve in my previous comment, do you have any tips at this point?

Another question, while I have your ear, is it possible to:

1. Save the user's payment info for later? I want to use this for setting up subscriptions
2. get the last 4 digits of the card number, card type (visa/mastercard/etc) and expiration date after onSuccess?

thanks in advance!

[j-em]

Depending on how you choose to structure your code, I think the big lines of the multi-step form you are describing above make sense.

As for your other questions, I just published a new version that hopefully will help with your use case.

Essentially the onSuccess prop on FormContainer now accepts a second argument, which correspond to all the actual submitted form values.

<FormContainer {...otherProps} onSuccess={(response, {cardNumber, cardCode, expDate}) => {...}} />

From there, you should be able to do anything you want with them. Store them in the state of something else, get the last 4 digits of the card number, etc...

Don't hesitate to let me know if you are hitting any other issues!