Update payment to be able to capture less than the authorized amount

[dkubb]

I have a use case where a customer would like to be able to apply discounts to a pending order as adjustments, then capture less than the authorized amount.

Currently if I was to capture a payment for an order by clicking on the checkbox, it would authorize the original full authorized amount, not the actual order amount:

What I want to be able to do is either:

1. have the payment amount displayed in an input field and be able to edit it to be less than or equal to the authorized amount
2. and/or have the amount default to the current order total as long as it is less than or equal to the authorized amount

I would be happy to submit a PR in the next day or two if this feature would be accepted.

[radar]

@dkubb I can definitely see that the payment amount and the balance due amount does not match up there... but I am not understanding how that came to be. Under what circumstances precisely does this issue occur?

[dkubb]

@radar I added an adjustment of -1.00 to the order. In my customer's case, they sometimes apply discounts based on lots of different criteria (is this a preferred customer, is this an employee, date, etc).

[radar]

Oh is that all?! Well then, that sounds pretty simple. Could you please submit a patch to provide edit functionality to the payments? I think that'll be all that is required here.

[huoxito]

Just curious here is that always ok then to capture an amount below the one authorized? gateways don't complain about that? stupid question? haha

[dkubb]

@radar thanks! yeah, it is pretty simple, but I wanted to make sure there wasn't some design decision preventing what I want to do.

@huoxito I don't know any payment gateways that have an issue with capturing an amount below the authorized amount.

To confirm I did a bit of research, and it looks like Shopify's own docs say you can capture something less than the authorization amount: http://docs.shopify.com/manual/your-store/3-orders/3-authorize-capture-payment#capture-payment-manually-every-order Given that they (presumably) use ActiveMerchant under the hood, I would think if there were exceptions they would specify them here.

The only restriction I could find is that you can only capture once, but I believe that may be a "lowest common denominator" type of constraint where only a few gateways allow multiple captures.

[JDutil]

@huoxito @dkubb while payment gateways don't care about capturing less than the authorized amount some payment gateways do only allow you to capture payment once. So if you are to capture less than the authorized amount for say splitting payments among multiple shipments it is gateway dependent. If you just want to capture a lesser amount, and not come back around again your fine with all the gateways I'm familiar with.

This is actually pretty similar to issue #2962 in which I'd like to enable multiple payment captures for the gateways that do support it. I think if you tackled this smaller issue your having with payments it would also certainly help get my split payment capturing work moving. I've been too wrapped up in a current client project to have the free time to work on this yet, but I will be soon most likely first thing after I wrap up this current project as it's top of my list for Spree improvements.

[dkubb]

@jdutil sounds good. I've been working on this feature for a client's site, and I will definitely have it functional early this week. I'll update this issue with the PR when I get it feature complete and fully tested.

[dkubb]

I've added the pull request #3765 to resolve this issue. I'd love to get some feedback if anyone's got a moment to review it.

[binaryphile]

I have a similar use case where a user mistakenly submitted quantity 2 for an item. We only authorize when the user submits and manually capture later, giving us a window to correct the order before capture.

In this case, we wanted to edit the quantity down, which we were able to do. However the payment still contained the original amount, so we were not able to capture. Does this patch fix the payment amount when the order is edited?

Thanks for any clarification.

[dkubb]

@binaryphile yeah, this PR will give you something like this:

Note the edit button beside the row. Clicking on the edit button changes the menu to:

You can click on the save icon to make the ajax request to the api end-point, or click on cancel to go back to the original amount. Tabbing away from the amount field also causes the amount to save. Invalid amounts are also handled properly.

EDIT: to answer your question more specifically, yes, this will solve your specific issue. It won't change the payment amount to match the order precisely, because there could be more than one payment, but it will allow you to manually change the payment amount to match the order total so it can be captured.

[binaryphile]

Awesome, great job! Hopefully this will make it into the 1-3-stable branch.

[radar]

@binaryphile This will not make it into the 1-3-stable branch, as per our Release Policy:

Three branches back from master (currently 1-3-stable) receives patches for major issues and security problems. The severity of an issue will be determined by the person investigating the issue. Absolutely no features, tweaking or API changes.

[binaryphile]

Thanks for the update. At this point, does that mean this change will only be in the 2.1 branch?

[dkubb]

I'm not sure. I know it applies cleanly to 2-1-stable and master (since I built it off master, and cherry-picked it onto a fork based on 2-1-stable). I don't know how far back it will apply cleanly though. I'd be happy to provide patches against 2-0-stable if @radar asks; assuming it doesn't just apply.

[radar]

I would class this as a new feature, and so we won't be applying it to 2-0-stable either, again as per the release policy.

On Fri, Sep 27, 2013 at 7:26 AM, Dan Kubb notifications@github.com wrote:

I'm not sure. I know it applies cleanly to 2-1-stable and master (since I built it off master, and cherry-picked it onto a fork based on 2-1-stable). I don't know how far back it will apply cleanly though. I'd be happy to provide patches against 2-0-stable if @radar asks; assuming it doesn't just apply.

Reply to this email directly or view it on GitHub: https://github.com/spree/spree/issues/3738#issuecomment-25205321

[radar]

Actually, on further revision, I would class this as a "minor issue" and therefore it can go in 2-0-stable as well.

[dkubb]

I'm going to mark this as closed because the PR was merged upstream.