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
[EMAIL PROTECTED]
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
