SJ: Good point, I agree. BJF: I have seen merchants that do an authorization and a capture (you called it "charged") at the time of the sale. I do know that's not the way it should happen, unless fulfillment is immediate. However, I don't know if the processors enforce the rules.
For example, from the Paymentech Orbital Gateway CNP Processing 101 document on page 13: http://newsroom.chasepaymentech.com/portal/server.pt?mode=2&uuID={661AD524-7249-B348-C946-73167ED62000} Auth Only and Auth Capture Auth Only is a transaction to verify cardholder funds only. Auth Only is typically used when merchants do not fulfill orders immediately (Future Fulfillment Model). Once an Order is fulfilled, the merchant will send a Mark for Capture (MFC) to the system to include this transaction in the next batch processed for funds settlement. Auth Capture is a transaction to verify cardholder funds as well as queuing the transaction for settlement funding. This transaction will be processed in the next batch processed for this merchant. Typically a merchant uses this combined transaction when the order can be fulfilled immediately (Immediate fulfillment Model). C > Date: Wed, 13 Feb 2008 12:23:08 -0800 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: CC declined, order rejected - how to keep the order, but allow > user to switch to a different pay > > 1) yes > 2) yes > 3) does not go to # at this time but would be able to be enabled by a > flag in the product store. > 4) no is is only in the context of the session of the user. > 5) not sure, think the cc is charged, not authorized at time of purchase. > > Christopher L sent the following on 2/13/2008 9:19 AM: > > 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: [email protected] > >> 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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > > >
