OFBiz
  1. OFBiz
  2. OFBIZ-1716

POS: CVV2 code is not always deleted from the DB

    Details

      Description

      I ran a transaction that was declined by the processor. I later noticed that the cvv2 code was still present in the database.

      1. ofbiz-1716.patch
        1 kB
        Chris Lombardi
      2. ofbiz-1716.patch
        2 kB
        Chris Lombardi

        Activity

        Hide
        Chris Lombardi added a comment -

        I have to go read the interchange guidelines to determine what is allowable for retention of cvv2 for retries in an ecommerce context. If anyone has any comments on this, please chime in.

        Here's the section that may need to be changed:

        PaymentGatewayServices: 1770

        if (context != null && authResult.booleanValue())

        { orderPaymentPreference.set("statusId", "PAYMENT_AUTHORIZED"); orderPaymentPreference.set("securityCode", null); orderPaymentPreference.set("track2", null); }

        else if (context != null && !authResult.booleanValue())

        { orderPaymentPreference.set("statusId", "PAYMENT_DECLINED"); }

        else

        { orderPaymentPreference.set("statusId", "PAYMENT_ERROR"); }
        Show
        Chris Lombardi added a comment - I have to go read the interchange guidelines to determine what is allowable for retention of cvv2 for retries in an ecommerce context. If anyone has any comments on this, please chime in. Here's the section that may need to be changed: PaymentGatewayServices: 1770 if (context != null && authResult.booleanValue()) { orderPaymentPreference.set("statusId", "PAYMENT_AUTHORIZED"); orderPaymentPreference.set("securityCode", null); orderPaymentPreference.set("track2", null); } else if (context != null && !authResult.booleanValue()) { orderPaymentPreference.set("statusId", "PAYMENT_DECLINED"); } else { orderPaymentPreference.set("statusId", "PAYMENT_ERROR"); }
        Hide
        Jacques Le Roux added a comment -

        Hi Chris,

        AS long as you don't persist the CV2 code in DB there is no problems to keep it in a session.

        Show
        Jacques Le Roux added a comment - Hi Chris, AS long as you don't persist the CV2 code in DB there is no problems to keep it in a session.
        Hide
        Jacques Le Roux added a comment -

        Hi Chris, All,

        I just had a look at it and yes indeed there seems to be a problem there...

        Show
        Jacques Le Roux added a comment - Hi Chris, All, I just had a look at it and yes indeed there seems to be a problem there...
        Hide
        Jacques Le Roux added a comment -

        I did not change it yet in the case of PAYMENT_DECLINED, since I think that, in such case, the transaction may be retried one or more times. If it's well done I suppose that at the end of transactions (with success or not) securityCode and track2 are "nullified" in the DB. So for now I only nullified int the case of PAYMENT_ERROR and I hope it's the exit door (did not look further)

        Show
        Jacques Le Roux added a comment - I did not change it yet in the case of PAYMENT_DECLINED, since I think that, in such case, the transaction may be retried one or more times. If it's well done I suppose that at the end of transactions (with success or not) securityCode and track2 are "nullified" in the DB. So for now I only nullified int the case of PAYMENT_ERROR and I hope it's the exit door (did not look further)
        Hide
        Chris Lombardi added a comment -

        I'm not sure of the scenario where you wouldn't just report back to the customer that their card has been declined and instead retain the cvv code for later retries.

        1. Online e-commerce
        2. POS
        3. Card taken over phone by sales
        4. Recurring subscriptions

        For cases 1, 2 and 3, just report back declined. The customer may enter in a different credit card. For case 4, you shouldn't retain the cvv code past the initial transaction.

        In reading the code, there was some retry logic for a not sufficient funds (nsf) case. Could anyone explain when this is actually used? I'm having a hard time figuring out when you wouldn't just report back to the customer with a decline.

        Show
        Chris Lombardi added a comment - I'm not sure of the scenario where you wouldn't just report back to the customer that their card has been declined and instead retain the cvv code for later retries. 1. Online e-commerce 2. POS 3. Card taken over phone by sales 4. Recurring subscriptions For cases 1, 2 and 3, just report back declined. The customer may enter in a different credit card. For case 4, you shouldn't retain the cvv code past the initial transaction. In reading the code, there was some retry logic for a not sufficient funds (nsf) case. Could anyone explain when this is actually used? I'm having a hard time figuring out when you wouldn't just report back to the customer with a decline.
        Hide
        David E. Jones added a comment -

        The NSF retry stuff can be used for any order, but is mostly intended for automatic orders done through ShoppingLists.

        Either way, it totally depends on business policy and desired process.

        For CVV codes it doesn't matter anyway. You cannot store or in any way remember them beyond the time scope of the transaction they were entered for (and if it is split into auth and capture then that would be ONLY the auth part you can keep the code for).

        That means for ALL automatic retries you will not have the CVV code, and will not get the benefit of the discounted transaction fee for having the CVV code. That's the only real difference.

        Again, it's all a business decision to be made with an understanding of these sorts of constraints. Whatever is done OOTB in OFBiz needs to be changeable to different situations. Well, it is always changeable, but the goal is to make more common variations easier to configure.

        Show
        David E. Jones added a comment - The NSF retry stuff can be used for any order, but is mostly intended for automatic orders done through ShoppingLists. Either way, it totally depends on business policy and desired process. For CVV codes it doesn't matter anyway. You cannot store or in any way remember them beyond the time scope of the transaction they were entered for (and if it is split into auth and capture then that would be ONLY the auth part you can keep the code for). That means for ALL automatic retries you will not have the CVV code, and will not get the benefit of the discounted transaction fee for having the CVV code. That's the only real difference. Again, it's all a business decision to be made with an understanding of these sorts of constraints. Whatever is done OOTB in OFBiz needs to be changeable to different situations. Well, it is always changeable, but the goal is to make more common variations easier to configure.
        Hide
        Chris Lombardi added a comment -

        I'll fix it to delete the cvv and track2 information per DJ's comment. JLR, do you have any objections?

        Show
        Chris Lombardi added a comment - I'll fix it to delete the cvv and track2 information per DJ's comment. JLR, do you have any objections?
        Hide
        Jacques Le Roux added a comment -

        Any objections this is fine with me

        Show
        Jacques Le Roux added a comment - Any objections this is fine with me
        Hide
        Chris Lombardi added a comment -

        I have to test this patch.

        Show
        Chris Lombardi added a comment - I have to test this patch.
        Hide
        Jacques Le Roux added a comment -

        Hi Chris,

        What is the status of this patch, now ?

        Thanks

        Show
        Jacques Le Roux added a comment - Hi Chris, What is the status of this patch, now ? Thanks
        Hide
        Chris Lombardi added a comment -

        I don't remember. The patch looks pretty straight forward though, I'll test it today.

        Show
        Chris Lombardi added a comment - I don't remember. The patch looks pretty straight forward though, I'll test it today.
        Hide
        Chris Lombardi added a comment -

        Updated patch to work with current trunk. Tested, works ok.

        Show
        Chris Lombardi added a comment - Updated patch to work with current trunk. Tested, works ok.
        Hide
        Jacques Le Roux added a comment -

        Thanks Chris,

        Your patch is in trunk revision: 672130 , release4.0 672133

        Show
        Jacques Le Roux added a comment - Thanks Chris, Your patch is in trunk revision: 672130 , release4.0 672133

          People

          • Assignee:
            Jacques Le Roux
            Reporter:
            Chris Lombardi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development