You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Dave Tenerowicz <dt...@salmonllc.com> on 2008/02/12 19:28:12 UTC
CC declined, order rejected - how to keep the order, but allow user
to switch to a different payment method
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
--
Dave Tenerowicz
dtenerowicz@salmonllc.com
Office: 303.493.6727
Mobile 303.906.6116
Fax 303.814.8331
Visit us at http://www.salmonllc.com
For ERP Information: http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by BJ Freeman <bj...@free-man.net>.
We have a box that if thier card is declined the order will have to
placed again. We suggest they put in as many forms of payment so if one
does not work, the system will automatically try the others they have
entered.
Dave Tenerowicz sent the following on 2/12/2008 2:23 PM:
> Thanks BJ
> That seems like a suggestion worth investigating. I'll let you know what
> we learn if we take that approach.
>
> This seems like a valuable general purpose approach - although there
> have been no other responses to this issue so far, I cannot believe that
> other companies do not encounter the same issue with declined credit
> cards. I mean, if you have taken the entire order and the cc is
> declined, certainly no one wants to have to recreate the order before
> they can associate an alternate payment method to the order.
>
> regards,
>
> Dave
>
> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by Dave Tenerowicz <dt...@salmonllc.com>.
Thanks BJ
That seems like a suggestion worth investigating. I'll let you know
what we learn if we take that approach.
This seems like a valuable general purpose approach - although there
have been no other responses to this issue so far, I cannot believe that
other companies do not encounter the same issue with declined credit
cards. I mean, if you have taken the entire order and the cc is
declined, certainly no one wants to have to recreate the order before
they can associate an alternate payment method to the order.
regards,
Dave
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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
--
Dave Tenerowicz
dtenerowicz@salmonllc.com
Office: 303.493.6727
Mobile 303.906.6116
Fax 303.814.8331
Visit us at http://www.salmonllc.com
For ERP Information: http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
Re: CC declined, order rejected - how to keep the order, but allow user to switch to a different payment method
Posted by David E Jones <jo...@hotwaxmedia.com>.
That is the best way to simulate a decline in development.
As for keeping an order when a card is declined I think you'll have to
make code changes. The default behavior is to reject the original
order and create a new one. In ecommerce and the order mgr the cart
retains all information, plus ID of the original rejected order. Then
the user can try again.
-David
On Feb 13, 2008, at 1:16 PM, Dave Tenerowicz wrote:
> Sorry guys, I found that I can avoid this problem by changing the
> Product Store settings for Header and Item Declined to "APPROVED".
> With this setting, it is possible to save the order and enter a
> different payment method, and then to get an authorization which
> Approves the order. So far, so good.
>
> However, once we attempt to Quick Ship this order (which had a
> payment declined, but now the payment with a new CC is authorized),
> we are unable to create the shipment (message something like :
> Shipment not created, no items to ship)
>
> I have traced this out, and when an OPP is declined a
> OrderItemShipGrpInvRes entry is not created. As a result when the
> Quick Ship button is used, the once declined, but now approved order
> generates an error because (I think) there is no entry in this table.
>
> Can anyone tell me how we can simulate credit card declines without
> breaking the quick ship functionality? Is changing the Product Store
> Payment setup for Payment Auth Service from
> "alwaysApproveCCProcessor" to "alwaysDeclineCCProcessor" the best/
> only way to simulate a cc decline?
>
> I appreciate any advice on how to test declines
> -Dave
>
>
>
> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Dave Tenerowicz
> dtenerowicz@salmonllc.com
>
> Office: 303.493.6727
> Mobile 303.906.6116
> Fax 303.814.8331
>
> Visit us at http://www.salmonllc.com
> For ERP Information: http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by Dave Tenerowicz <dt...@salmonllc.com>.
Sorry guys, I found that I can avoid this problem by changing the
Product Store settings for Header and Item Declined to "APPROVED". With
this setting, it is possible to save the order and enter a different
payment method, and then to get an authorization which Approves the
order. So far, so good.
However, once we attempt to Quick Ship this order (which had a payment
declined, but now the payment with a new CC is authorized), we are
unable to create the shipment (message something like : Shipment not
created, no items to ship)
I have traced this out, and when an OPP is declined a
OrderItemShipGrpInvRes entry is not created. As a result when the Quick
Ship button is used, the once declined, but now approved order generates
an error because (I think) there is no entry in this table.
Can anyone tell me how we can simulate credit card declines without
breaking the quick ship functionality? Is changing the Product Store
Payment setup for Payment Auth Service from "alwaysApproveCCProcessor"
to "alwaysDeclineCCProcessor" the best/only way to simulate a cc decline?
I appreciate any advice on how to test declines
-Dave
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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>
>
>
--
Dave Tenerowicz
dtenerowicz@salmonllc.com
Office: 303.493.6727
Mobile 303.906.6116
Fax 303.814.8331
Visit us at http://www.salmonllc.com
For ERP Information: http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different pay
Posted by Dave Tenerowicz <dt...@salmonllc.com>.
Christopher L wrote:
> 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.
>
If you set Header Declined and Item Declined values in the Product store
to Approved it will go back to 2. By default these are set to Rejected,
in which case the process dead ends with a declined OrderPayPref and a
Rejected Order
> 4) The authorization code is stored.
>
I believe stored in PaymentGatewayResponse
> 5) Merchant ships product and sends a "capture" event to the credit card processor with the authorization code.
>
On Order approval an authorization is captured. This may be over ridden
by a forced approval of order.
The capture is done either on Packing or Shipment - I don't recall which
> 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: rajsaini@gmail.com
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>
--
Dave Tenerowicz
dtenerowicz@salmonllc.com
Office: 303.493.6727
Mobile 303.906.6116
Fax 303.814.8331
Visit us at http://www.salmonllc.com
For ERP Information: http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different pay
Posted by BJ Freeman <bj...@free-man.net>.
I am only speaking of ofbiz capabilities as it is implemented now.
yes many of my customers authorize first then charge once shipped.
The routines are there to implment.
It has become more difficult to implement changes in order flow with the
addition of the accounting.
Christopher L sent the following on 2/13/2008 2:08 PM:
> 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: bjfree@free-man.net
>> To: user@ofbiz.apache.org
>> 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: rajsaini@gmail.com
>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>
RE: CC declined, order rejected - how to keep the order, but allow
user to switch to a different pay
Posted by Christopher L <cl...@hotmail.com>.
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: bjfree@free-man.net
> To: user@ofbiz.apache.org
> 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: rajsaini@gmail.com
> >> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different pay
Posted by BJ Freeman <bj...@free-man.net>.
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: rajsaini@gmail.com
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different pay
Posted by Raj Saini <ra...@gmail.com>.
Christopher L wrote:
> If the customer enters a new card, the new card will have a new cvv.
>
For registered users credit cards are stored and CVV code is not stored
along with card as it is prohibited by credit card companies. Customers'
can store more than one credit cards and choose one of them during
checkout. CVV code is entered at the time of checkout.
> 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: rajsaini@gmail.com
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>
RE: CC declined, order rejected - how to keep the order, but allow
user to switch to a different pay
Posted by Christopher L <cl...@hotmail.com>.
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: rajsaini@gmail.com
> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by Raj Saini <ra...@gmail.com>.
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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by BJ Freeman <bj...@free-man.net>.
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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by Raj Saini <ra...@gmail.com>.
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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by BJ Freeman <bj...@free-man.net>.
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
>>>
>>>
>>>
>>
>>
>>
>>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by Dave Tenerowicz <dt...@salmonllc.com>.
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
>>
>>
>>
>
>
>
>
--
Dave Tenerowicz
dtenerowicz@salmonllc.com
Office: 303.493.6727
Mobile 303.906.6116
Fax 303.814.8331
Visit us at http://www.salmonllc.com
For ERP Information: http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by BJ Freeman <bj...@free-man.net>.
guess I should finish the thought.
alwaysDeclineProcessor is a test service.
if you look at authOrderPaymentPreference()
you will see that it will try all the CC on file at the time.
There is more than just changing the Status.
BJ Freeman sent the following on 2/12/2008 11:04 AM:
> 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
>>
>>
>
>
>
>
Re: CC declined, order rejected - how to keep the order, but allow
user to switch to a different payment method
Posted by BJ Freeman <bj...@free-man.net>.
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
>
>