Advance Payment not automatically captured

[domeglic]

When paying with advance payment, an invoice is created when the customer pays. Order is marked as fully paid and goes into processing however the payment is not really captured.

Is there a reason why it does not capture automatically? Maybe I am missing some configuration. Having to manually confirm hundreds of payments each day is not a very good solution.

[fjbender]

I think this is related to #100. We're currently looking into this and will fix this soon.

[fjbender]

Hasn't this been fixed with #105 ?

[domeglic]

No, that solution fixes another problem. My issue is actually exactly what @fischamhaken wrote in #100: Having to manually capture hundreds of orders every day.

This is actually the same "problem" that also exists in the Magento-1 version, but I still don't understand why. When calling Payone Support nobody could explain exactly why this is.

[fjbender]

Okay, maybe what you guys are trying to do is better solved using "authorization" mode instead of "preauthorization". "authorization" constitutes an immediate sale, thus no separate capture is needed. However, you'd need to pay attention to the status mapping, so orders don't slip into "processing" too early.

EDIT: Doesn't, see below.

[lfritsche]

Hi @fjbender just diving into the discussion about status mapping. It's off-topic, because I have the issue with magento1/payone/paypal. But what do you mean by "slip into processing too early". I think that I'm facing this exact issue. The status mapping stucks on "running" afterwards on every transaction update. Sounds like a known issue? Thank you :)

[domeglic]

If we use authorization then we cannot create creditmemos.

Currently what we have to do is: Wait for status Paid then click on button to invoice. I don't see a difference between a person clicking on invoice and a script doing it automatically.

[lfritsche]

Regarding creditmemo on authorization mode. We also don't see the option to refund via invoice. @domeglic That's much time, if you capture hundreds orders daily: Have you tried as a workaround, to use a extension like Xtento sales export extension (automatically invoice on export) or bulk order processing (manually create online invoice for all selected orders in grid) and trigger the invoice some minutes after the order or on a specific status. (disclaimer: I just like the extensions and those guys and use it in almost every project for automation processes).

[fjbender]

Okay, well. Thank you guys for bearing with me here.

Prepayment in combination with authorization is not recommended by our product guys for various reasons, as there a quite some side effects, which you are also experiencing. So back to the beginning.

What we need to do here is the following:

• User sends in order, order is sent to payone with preauthorization (works)
• User wires money, Magento is notified that the amount has been paid (works so far)
• To finalize the transaction, a capture is needed. Currently, the capture is performed manually, which is (understandably) not a good way.
• However: an automatic capture can't always be issued, as sometimes the customer doesn't pay the right amount of money. This can be seen in the transaction status "price" and "balance" fields.

We'll need to remodel the advance payment stuff in Magento to reflect on this issue. I am, however, not yet sure how. Probably it's gonna be some kind of observer looking into the transaction status "price" and "balance" fields and then issuing an automatic capture if all conditions are satisfied. I'll have to clarify this internally first to see, how this entire process is intended.

Thanks Florian

[jaykobi]

@domeglic

If we use authorization then we cannot create creditmemos.

Yes, you can. You cannot change the order (like bought articles) and you cannot cancel ist. But sure you can create creditmemos.

[domeglic]

@lfritsche Having an option included in the extension would help so no additional code is needed. There is also no possibility of doing something wrong.

@fjbender Doesn't the Paid status already indicate that the payment was successful? If the customer doesn't pay enough then status Underpaid is received instead.

@skymeissner I didn't really check in Magento-2 version, but in the previous one it didn't work correctly which is how I found out that Advance Payment is only supposed to work with Authorization like @fjbender explained.

[fischamhaken]

Hi Florian, thank you very much for your explanation of the payment sequence :-) Let me add some information. As Payone Tech-Support told me, Status paid is only transfered if full amount was passed. So it could happen an overpayment, but no underpayment.

In case of overpayment its ok to capture invoice with the regular amount. One can refund the overpayment in PMI.

Here is how it could work: 1) User sends in order, order is sent to payone with preauthorization (ok) 2) User wires money, Magento is notified that the amount has been paid (status switch from pending_payment to paid - only when he has paid full - ok) 3) Extension captures invoice online to finalize the transaction (with amount of order! ok.) 4) If customer did an overpayment, refund can be made in PMI

@lfitsche: a notice on the edge: the guys from xtento are really good :-) I am waiting for the upcoming extensions, order import and product import.

Cheers, Stefan

[fjbender]

@fischamhaken Correct, that's why I added an additional condition:

However: an automatic capture can't always be issued, as sometimes the customer doesn't pay the right amount of money. This can be seen in the transaction status "price" and "balance" fields.

However, please don't expect a solution to this problem too soon - I'll have to clarify this with other stakeholders within the company first.

[fjbender]

@domeglic

Doesn't the Paid status already indicate that the payment was successful? If the customer doesn't pay enough then status Underpaid is received instead.

Yes, but if something is overpaid, a capture with the increased amount would fail, so this is something we'll have to pay attention to and clarify that the overpaid amount has to be refunded, as Stefan noted.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.