Cybersource rejects e-commerce payments in a specific case

[Frane Kalebic]

Hi everybody, 

per clients request I've changed e-commerce on my dev insance to be able to add a 0% coupon. 

The coupuns work fine (with a cybersource test account) when created for courses added as "Verified" on e-commerce, but when I try to use them with courses of the "Professional education" type, I got the following error:

There was a problem with your transaction. You have not been charged.

Make sure your information is correct, or try again with a different card or another type of payment.

Logs give me:

ip-10-164-101-184 [service_variant=ecommerce][ecommerce.extensions.payment.views][env:no_env] INFO [ip-10-164-101-184  19258] [views.py:129] - CyberSource payment did not complete for basket [62] because [TransactionDeclined]. The payment response was recorded in entry [17].

When I log into my Cybersource account, i see that the Credit Card Authorization has failed with the following message:

There is a problem processing this request: Processor sent a partial auth response for a non-partial auth transaction. 

Does anybody have any idea why this happens and how could I correct it?

Any help would be appreciated

[Clinton Blackburn]

Check the data being sent to CyberSource to ensure the amounts all add up. Adding a debug call to ecommerce/extensions/payment/processors/cybersource.py:get_transaction_parameters() should suffice.

Also, depending on the amount of the transaction, you may have triggered a simulated response. See the appropriate responses for your payment processor at http://www.cybersource.com/developers/getting_started/test_and_manage/simple_order_api/. By default, you should be configured for Chase Paymentech.

Clinton Blackburn, Tech Lead

edX E-Commerce Engineering

[Frane Kalebic]

Thank you for your answer,

The transactions parameters seemed ok, so I tried changing the amount of the transaction.

It seems the issue was in the account I was trying to charge (1000 USD). When I reduced that to 999 the payment went through. 

Could it be that all 4 digit amounts are set to return REJECT, except the ones explicitly stated in the input/output table you linked?

Later i tried it with 2835 (since that is one of the amounts in the table that should return an ACCEPT response) and it worked.