If the customer enters a new card, the new card will have a new cvv. So I can keep things straight, here's a simplified outline of my understanding of the normal process flow in credit card payment acceptance for physical goods over the internet.
1) Customer puts items in shopping cart. 2) Customer goes through checkout process and enters payment information including credit card number and cvv code. 3) If the card is rejected, the customer goes back to step 2. Else the authorization was successful, goto 4. 4) The authorization code is stored. 5) Merchant ships product and sends a "capture" event to the credit card processor with the authorization code. Does the ecommerce application not send the customer back to "step 2" in the event of a declined credit card? If so, that should be changed. The only times I could see wanting to retry a credit card after a decline for "not sufficient funds" is if there is a subscription type model where the card is charged without customer input (i.e. health club, magazine, etc) at intervals. Otherwise, you should just ask for an alternate payment method. My 2c. Chris Lombardi > Date: Wed, 13 Feb 2008 21:59:03 +0530 > From: [EMAIL PROTECTED] > To: user@ofbiz.apache.org > Subject: Re: CC declined, order rejected - how to keep the order, but allow > user to switch to a different payment method > > It is more of a credit card security and not technical issue. > > What I mean was, security code like CVV is not stored as part of the > credit card info. CVV code can only be entered by the customer at the > time of checkout. There is no way to authorize the new card as security > code is not stored. > > Raj > BJ Freeman wrote: > > By using SECAS you can check for the fields that are passed. > > if the cc provider provides the CVV code it can be check and then the > > same service that is called by the reject code can be called by the SECAS. > > > > here is an example: > > here is how a rule looks in ofbiz > > <eca service="createPaymentFromPreference" event="return" > > > <condition field-name="gatewayAvsResult" operator="equals" > > value="XXU"/> > > <set field-name="statusId" value="ORDER_FraudCheck"/> > > <action service="ChangeStatus" mode="async"/> > > </eca> > > > > > > > > Your second suggestion can be done, but also takes more consideration as > > to how to Flag that type of operation, or just hard code it. > > > > Raj Saini sent the following on 2/12/2008 10:14 PM: > > > >> If I am getting it correctly, it is possible to have store setting > >> (something like nsfRetry) that not to retry the CC. If CC is declined, > >> customer will be sent back to the payment page again where customer can > >> enter the new credit card detail. He/she does not need to renter the > >> order. This is how it is working for me. > >> > >> Alternatively, you can send a mail on order rejection to customer and > >> asking them to add/modify the credit card. On next CC retry new card > >> should be used. Though, I am not sure how it can work with CVV. > >> > >> Raj > >> > >> > >> BJ Freeman wrote: > >> > >>> maybe a way to approach this is to allow a parm that can be set for the > >>> store so the process is changed if the card is declined and send the > >>> customer back so they can enter a new CC. > >>> > >>> > >>> Dave Tenerowicz sent the following on 2/12/2008 12:21 PM: > >>> > >>> > >>>> Sorry, perhaps I was not clear. The issue is not retrying the same CC, > >>>> it is using a new CC to pay for the order > >>>> > >>>> The scenario is that the card is declined and will never be authorized. > >>>> The Customer wants to place the order and the order taker simply wants > >>>> to use a DIFFERENT credit card number to pay for the order. As things > >>>> function out of the box, the only recourse for the user is to re-enter > >>>> the order (again) and associate it with a different payment method (CC > >>>> or other). This is what we need to avoid - it is too cumbersome for the > >>>> user > >>>> > >>>> Thanks for any suggestions > >>>> > >>>> -Dave > >>>> > >>>> BJ Freeman wrote: > >>>> > >>>> > >>>>> there is a service retryFailedAuthNsfs > >>>>> it is automatically run every day. > >>>>> https://demo.hotwaxmedia.com/webtools/control/availableServices?sel_service_name=retryFailedAuthNsfs > >>>>> > >>>>> > >>>>> needsNsfRetry is set in the OrderPaymentPreference > >>>>> > >>>>> look in > >>>>> applications/Accounting/src/org/ofbiz/accounting/payment/PaymentGatewayServices.java > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Dave Tenerowicz sent the following on 2/12/2008 10:28 AM: > >>>>> > >>>>> > >>>>> > >>>>>> In order to test default functionality when a credit card payment > >>>>>> on an > >>>>>> order is declined, we changed the settings in Product Store, Payments > >>>>>> tab for Payment Auth service to alwaysDeclineCCProcessor. > >>>>>> > >>>>>> Then we tested by creating an order and submitting a CC# as a payment > >>>>>> method. Of course the CC was declined, and the Order status was set to > >>>>>> ORDER_REJECTED, OrderITemStatus was also set to rejected. Since > >>>>>> there is > >>>>>> no valid status change allowed from ORDER_REJECTED to anything else, > >>>>>> there appears to be no way to take the existing order, assign a new > >>>>>> paymentMethodId and reattempt authorization with a different credit > >>>>>> card. Is this true? > >>>>>> > >>>>>> To remedy this, we could add an entry to StatusValidChange that > >>>>>> allows a > >>>>>> movement from ORDER_REJECTED back to ORDER_APPROVED, modify secas.xml > >>>>>> and theoretically that should allow the user to select an alternate > >>>>>> payment method from the Order Detail screen and reprocess payment. > >>>>>> > >>>>>> Is this the best way to handle this? The requirement is to allow an > >>>>>> order taker to switch to a different credit card if the first one is > >>>>>> declined - without having to completely re-enter the order. > >>>>>> > >>>>>> If anyone has encountered this before, or has a suggestion about an > >>>>>> approach, that would be most welcome. Thanks > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>> > >>> > >> > >> > >> > > > > > > >
