Skip to content

Conversation

Korri
Copy link
Contributor

@Korri Korri commented Feb 27, 2018

If the CVV2 is available, it should be sent with the transaction so Payflow can check it if it was not done before.

Korri and others added 2 commits February 27, 2018 11:18
If the CVV2 is available, it should be sent with the transaction.
@RobvH
Copy link
Contributor

RobvH commented Mar 2, 2018

Does this actually work? I’m surprised that Payflow would re-perform CVV2 AVS on a reference transaction.

Unsolicited advice:
From a design standpoint using it on your ref sales forces them into your PCI compliance audit surface area. Better to use transparent redirect for authorization and then pnref only for repeated sales so that your server has no PCI obligations.

@Korri
Copy link
Contributor Author

Korri commented Mar 5, 2018

Hi @RobvH it does work, we use the forked version internally right now.

As to why we do it that way, its because we use other plateforms for payment to, and those require us to tokenize the card before doing the transaction, so we do tokenization & capture in the same web request, allowing us to later re-use the card if needed.
We don't actually send the CVV again with further transations, just with the first one.

@RobvH
Copy link
Contributor

RobvH commented Mar 6, 2018

@Korri Thanks for the explanation! It's a well written PR.

We also tokenize first; using an authorization request then saving the PNREF for use on future reference sale transactions. We do our CVV & Zip validation on the auth request. The $1 authorize gets automatically captured on the first sale and the PNREF remains good for sales for a year. We do re-authorizations at those times.

@Korri
Copy link
Contributor Author

Korri commented Mar 6, 2018

@RobvH Yeah, you use the AuthorizeRequest to tokenize, Payflow supports that, but some other plateforms don't.

What we do is start with a CreateCardRequest followed immediately with an AuthorizeRequest, that's why the AuthorizeRequest actually uses the card reference from the CreateCardRequest but still needs the CVV & ZIP to do validation (as The CreateCardRequest does not return do/return CVV/ZIP validation)

@delatbabel delatbabel merged commit 88fb22e into thephpleague:master Apr 11, 2018
@delatbabel
Copy link
Contributor

OK I'll go with the consensus and merge this, it doesn't look like it breaks anything since if the card is not defined or null it doesn't try to send an empty CVV. Can someone please confirm that this works in production and then I will tag for release.

@Korri Korri deleted the patch-1 branch April 11, 2018 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants