AuthorizeDotNet payment processor: can't charge $0.00.

[eigood]

<?xml version="1.0" encoding="utf-8"?><ErrorResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00003</code><text>The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:amount' element is invalid - The value &amp;#39;0&amp;#39; is invalid according to its datatype 'Decimal' - The MinInclusive constraint failed.</text></message></messages></ErrorResponse>

We create an order, attach a payment method, add products with quantities. Then, a promo rule applies that discounts certain products 100%. If the order only contains those discounted products, then the cost of the order ends up being totally 0. Then the CimPayment service(s) send this $0.00 charge over to Authorize.Net, which gives back an error.

[eigood]

I would have thought that something further up the processing chain would skip such processing. In our case, the accounting system gets updated properly, showing as a cost-of-doing-business in the promotions category; we like that.

[jonesde]

Which service are you calling, or which is triggered? Is it a direct call to an AuthorizeNet service, or a higher level call to one of the mantle-usl services?

[eigood]

We add products to an order. Then we have a custom promo handler that adds a 100% discount to the order, so that the orderTotal=0. Then we transition the order from APPROVED to COMPLETED state. All payment gateway processing that you are asking about it done automatically by moqui.

[jonesde]

Thanks Adam... I looked into this a bit and made some changes in commit f305b51. The new behavior for 0.0 amount payments is to skip the gateway auth and capture, and just update the Payment status to Authorized and then Delivered. In that commit there are a few other changes to better handle 0.0 amounts, and to not better handle multiple payments associated with an OrderPart and how the amount defaults to the remaining amount... which is not part of this issue but something that annoyed me when trying to create data to test with, and it wasn't behaving in a great way.

If that fixes it for you, or is similar to the fix you came up with, we can close this issue... otherwise let me know what sort of annoyances you're still running into.

[eigood]

Thanks for looking into this; I'll see about getting this update deployed in the new few weeks.

…

On Sun, Jul 18, 2021 at 2:33 PM David E. Jones ***@***.***> wrote: Thanks Adam... I looked into this a bit and made some changes in commit f305b51 <f305b51>. The new behavior for 0.0 amount payments is to skip the gateway auth and capture, and just update the Payment status to Authorized and then Delivered. In that commit there are a few other changes to better handle 0.0 amounts, and to not better handle multiple payments associated with an OrderPart and how the amount defaults to the remaining amount... which is not part of this issue but something that annoyed me when trying to create data to test with, and it wasn't behaving in a great way. If that fixes it for you, or is similar to the fix you came up with, we can close this issue... otherwise let me know what sort of annoyances you're still running into. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#167 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4YMNXYF6FUM6QXSNPTAWDTYMUAZANCNFSM45DCW26Q> .