These release notes describe the changes in versions 28.0.2609.816, 27.0.2609.823 and 26.0.2609.825 of the collana pay app from 02.09.2026.

Bug Fixes

Rounding differences in partial claims no longer block refunds

Business Central recalculates discount and VAT rounding for every partial claim. As a result, the amounts of several partial claims for the same invoice line can differ from the captured amount by a few cents. Such claims were previously rejected with the error No capture was found for the given return order and could only be posted using Force Credit.

• Refunds now tolerate these cent differences, up to one cent per captured unit
• The refunded amount is now automatically capped at the remaining captured amount – a refund can therefore never exceed the capture
• For documents with prices excluding VAT, the proportional line discount used to match claim lines with captured items was calculated incorrectly; this has also been corrected

Auto Capture and Auto Void notifications are now processed correctly

Notifications about captures and voids that the PSP performs automatically (Auto Capture / Auto Void) previously remained stuck with an error.

• Such notifications are now processed, or completed with an explanatory note; if needed, the capture log entry is created from the notification and the transaction is marked as captured
• The color highlighting of the status text in the transaction log now also works correctly in non-English sessions

Multiple refunds for the same invoice and item work again

The check on whether a capture can be used for a refund is now based on the remaining refundable amount instead of the quantity. A capture can be used for refunds until its amount is exhausted.

• This means multiple claims for the same posted invoice and the same item work again – for example a partial credit memo followed by a return of the item, even with a 100% line discount
• The error No capture was found for the given return order no longer occurs in these cases; the error message has been revised accordingly
• For existing installations: quantity no longer blocks a refund, the amount is decisive. A claim whose amount exceeds the remaining capture amount is still rejected

Missing items on the capture log entry when posting without cart transfer fixed

For transactions without cart transfer (No Cart), capture log entries created from a status inquiry (e.g. for Auto Capture) remained without transaction items whenever another log entry already had items. This caused the error Item ... not found in Transaction Items ... during the Amount Clearing process when posting the sales order, even though the invoice had already been posted at that point.

• The transaction items are now also transferred to the capture log entry in this case, so posting completes without errors
• The transfer only happens when it is unambiguous: exactly one successful capture whose amount matches the sales lines, and a payment process that has not progressed any further
• If the amounts differ, no items are transferred; releasing stops at the existing sales line check. The case can be resolved with a new transaction with corrected sales lines
• Nothing changes for transactions with cart transfer

Improvements & Extensions

Optimized capture selection for refunds (Tightest Fit)

When multiple captures can serve a refund, the capture with the most matching lines is still selected. In case of a tie, the capture with the lowest remaining refundable amount that still covers the line is now selected, instead of the first one found.

• This means partial refunds consume already-used captures first; fuller captures remain available for later refunds with higher amounts
• The error No capture was found for the given return order caused by remaining amounts spread across multiple captures is thereby avoided
• For existing installations: a refund may now use a different capture than before; the refunded amounts remain unchanged

PayPal Express import: Transaction Identifier 1 used as capture/authorization ID

When importing PayPal transactions, the PayPal ID stored in Transaction Identifier 1 is automatically submitted as the capture or authorization ID.

• This special handling now also applies to the PayPalExpress payment method; the ID no longer needs to be entered in Transaction Identifier 2

Clearer error message for unmatched cart items

When a cart item reported by collana pay as shipping costs or a voucher cannot be matched to any transaction item – typically because the collana pay subtype is not set on the item or resource – the error message now points to this possible cause.

• The error also provides a link to the affected transaction; the transaction GUID is included in the detailed message
• The matching logic itself remains unchanged

New publishers and integration events

New publisher: OnAfterUpdatePayByLink

The event publisher OnAfterUpdatePayByLink in the codeunit PAY WebServ Communication HVE is triggered as soon as a notification contains a payment link that differs from the one previously stored on the transaction – i.e. on the first link or when an expired link is renewed.

• Extensions can use this to trigger follow-up actions, for example resending the payment link email
• The previous link is passed along, so the first link and the renewal can be distinguished
• Nothing changes for existing installations as long as no extension subscribes to the event