Paymos for Easy Digital Downloads

Changelog

1.6.2

• fix(cms): align marketplace manifests, refund copy, store links, and release guards
• chore: bundle Paymos PHP SDK v1.9.1
• chore: rebuild canonical CMS package

1.6.1

• fix(plugins): use wp_add_inline_script, sanitize nonces before wp_verify_nonce, and guard curl_close on PHP 8+

• chore: bundle Paymos PHP SDK v1.9.1

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.6.0

• feat(refunds): finalize clean merchant refunds spec, SDKs, CMS plugins, and targeted test scripts
• wip: snapshot shared working tree before merging main
• wip(refunds): merchant refund plugin work (CMS adapters, PHP SDK, tests) – unverified WIP snapshot
• chore: bundle Paymos PHP SDK v1.9.0

• chore: rebuild canonical CMS package

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.5.4

• chore: bundle Paymos PHP SDK v1.8.1

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.5.3

• chore: rebuild canonical CMS package

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.5.2

• fix(edd): validate refund controls and prepare directory database queries

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.5.1

• fix(plugins): require helper-complete PHP SDK for refunds

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.5.0

• fix(ton): return friendly addresses with existing webhook schema
• feat(edd): native refund adapter for full and overpayment refunds
• fix(edd): refuse native refunds that bypass the Paymos gateway
• fix(edd): prepare clean WordPress.org distribution
• chore: bundle Paymos PHP SDK v1.8.0

• chore: rebuild canonical CMS package

• Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.4.10

• chore: rebuild canonical CMS package

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.

1.4.9

• chore: rebuild canonical CMS package

• Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.

• Serialize order updates and recover when native payment completion returns false from save or status updates.
• Check ownership when updating event reservations, and purge at most 100 expired records per reservation.

Fixed:
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish and Chinese, Webhook URL in
Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* A late non-final webhook could reopen a finished order. Webhooks are
delivered at least once and in no particular order, and only paid orders were
guarded: an invoice.underpaid_waiting or invoice.confirming arriving after
the invoice had already ended underpaid, expired or cancelled moved the order
back into an open state. Nothing leaves a final status on the server, so once
one is recorded for an invoice every later event for it is ignored and the
final status stays recorded.
* A new invoice now resets the Paymos status recorded on the payment, so an
event for it is never taken for a stale one after an earlier final status.
* A webhook retry that arrived while the first delivery was still being
processed was answered 200 “duplicate”. Paymos gives a delivery 10 seconds and
retries, while a slow reverse-verification call can take longer; the retry was
acknowledged as delivered, and if the first attempt then failed the event was
lost. An event that is only locked, not yet committed, is now answered 409 so
Paymos tries again, and the lock the first delivery holds is left alone.