Paymos Stablecoin Checkout for WooCommerce

Changelog

1.5.3

• 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.
• Continue reconciliation in later batches after the first 50 orders, so older pending orders also get checked.

Fixed:
* When the checkout could not replace an order’s invoice (BUG-166), the order
note read “Paymos payment amount needs manual review.” although the block
also follows a mode or project change, and the buyer read “Paymos payment
error: unable to create invoice.” (BUG-181). The note is now “Paymos payment
needs manual review.” followed by the SDK’s summary of the old invoice’s
state, and the buyer reads the SDK’s buyer message, “The store needs to
review this order before payment can continue. Please contact the store.”
Both strings are in the .pot and translated in every .po/.mo.
* A changed order could leave its old invoice payable beside the new one
(BUG-166). When the order total, the mode or the project changed, the
checkout cut a new invoice and left the old one open on Paymos, so a buyer
could pay both. The old invoice is now cancelled first, in its own
environment, through the SDK’s InvoiceReplacement; the new one is cut only
after that cancel succeeds or Paymos reports the old one expired, cancelled
or underpaid. When the old invoice is paid, still payable (network picked,
funds confirming, part paid) or cannot be read — a 404 included — no new
invoice is cut and the order is put on hold with a note naming the old
invoice.
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish, the plugin name and
Webhook URL in Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* The reconciler compared amounts as strings. The snapshot is written with two
decimals and the server echoes a fiat amount at the currency’s own scale, so a
JPY order (2500.00 against 2500) never matched and the fallback for a lost
webhook skipped it on every run. Amounts are now compared numerically.
* The reconciler re-applied final statuses every ten minutes. Cancelled and
failed orders were fetched and re-noted on each run — thirty cancellations
meant thousands of identical notes and API calls a day — and, sharing one
“newest 50” window with them, an order stuck on hold could fall out of reach.
Orders whose invoice is already final are no longer fetched, an unchanged
status writes nothing, waiting orders get their own window, and an invoice
that was simply not paid yet is no longer described as a rolled-back payment.
* 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.
* Paying again for a failed or re-opened order led to a dead invoice. The
order kept its external_order_id, and the server answers a repeated id with
the same invoice — underpaid, expired or cancelled — so both checkout and
Pay invoice in My Account sent the buyer to a checkout that could no
longer be paid. Such an order now gets a fresh invoice, Pay invoice is
offered only while the invoice is still open, and the invoice deadline is
kept on the order.
* 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.
* A second invoice could be cut while the first could still be paid. Picking a
network moves the invoice deadline on the server (now + PaymentTtl) and
sends no webhook, but the order kept the deadline from creation; once that
passed, paying the order again minted a new external_order_id without asking
the server. The stored id is now always tried first — the server answers it
with the live invoice — and a new invoice is cut only if the server says the
old one ended unpaid or was never started. An invoice the server holds open
(network picked, funds confirming, part paid) is kept, and its status and
deadline are refreshed on the order. A stored id from another environment or
project gets a new one, since the server refuses it there.

1.5.2

• fix(plugins): reject invalid Woo refund controls and unblock SDK checks

• 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.
• Continue reconciliation in later batches after the first 50 orders, so older pending orders also get checked.

Fixed:
* When the checkout could not replace an order’s invoice (BUG-166), the order
note read “Paymos payment amount needs manual review.” although the block
also follows a mode or project change, and the buyer read “Paymos payment
error: unable to create invoice.” (BUG-181). The note is now “Paymos payment
needs manual review.” followed by the SDK’s summary of the old invoice’s
state, and the buyer reads the SDK’s buyer message, “The store needs to
review this order before payment can continue. Please contact the store.”
Both strings are in the .pot and translated in every .po/.mo.
* A changed order could leave its old invoice payable beside the new one
(BUG-166). When the order total, the mode or the project changed, the
checkout cut a new invoice and left the old one open on Paymos, so a buyer
could pay both. The old invoice is now cancelled first, in its own
environment, through the SDK’s InvoiceReplacement; the new one is cut only
after that cancel succeeds or Paymos reports the old one expired, cancelled
or underpaid. When the old invoice is paid, still payable (network picked,
funds confirming, part paid) or cannot be read — a 404 included — no new
invoice is cut and the order is put on hold with a note naming the old
invoice.
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish, the plugin name and
Webhook URL in Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* The reconciler compared amounts as strings. The snapshot is written with two
decimals and the server echoes a fiat amount at the currency’s own scale, so a
JPY order (2500.00 against 2500) never matched and the fallback for a lost
webhook skipped it on every run. Amounts are now compared numerically.
* The reconciler re-applied final statuses every ten minutes. Cancelled and
failed orders were fetched and re-noted on each run — thirty cancellations
meant thousands of identical notes and API calls a day — and, sharing one
“newest 50” window with them, an order stuck on hold could fall out of reach.
Orders whose invoice is already final are no longer fetched, an unchanged
status writes nothing, waiting orders get their own window, and an invoice
that was simply not paid yet is no longer described as a rolled-back payment.
* 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.
* Paying again for a failed or re-opened order led to a dead invoice. The
order kept its external_order_id, and the server answers a repeated id with
the same invoice — underpaid, expired or cancelled — so both checkout and
Pay invoice in My Account sent the buyer to a checkout that could no
longer be paid. Such an order now gets a fresh invoice, Pay invoice is
offered only while the invoice is still open, and the invoice deadline is
kept on the order.
* 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.
* A second invoice could be cut while the first could still be paid. Picking a
network moves the invoice deadline on the server (now + PaymentTtl) and
sends no webhook, but the order kept the deadline from creation; once that
passed, paying the order again minted a new external_order_id without asking
the server. The stored id is now always tried first — the server answers it
with the live invoice — and a new invoice is cut only if the server says the
old one ended unpaid or was never started. An invoice the server holds open
(network picked, funds confirming, part paid) is kept, and its status and
deadline are refreshed on the order. A stored id from another environment or
project gets a new one, since the server refuses it there.

1.5.1

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

• 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.
• Continue reconciliation in later batches after the first 50 orders, so older pending orders also get checked.

Fixed:
* When the checkout could not replace an order’s invoice (BUG-166), the order
note read “Paymos payment amount needs manual review.” although the block
also follows a mode or project change, and the buyer read “Paymos payment
error: unable to create invoice.” (BUG-181). The note is now “Paymos payment
needs manual review.” followed by the SDK’s summary of the old invoice’s
state, and the buyer reads the SDK’s buyer message, “The store needs to
review this order before payment can continue. Please contact the store.”
Both strings are in the .pot and translated in every .po/.mo.
* A changed order could leave its old invoice payable beside the new one
(BUG-166). When the order total, the mode or the project changed, the
checkout cut a new invoice and left the old one open on Paymos, so a buyer
could pay both. The old invoice is now cancelled first, in its own
environment, through the SDK’s InvoiceReplacement; the new one is cut only
after that cancel succeeds or Paymos reports the old one expired, cancelled
or underpaid. When the old invoice is paid, still payable (network picked,
funds confirming, part paid) or cannot be read — a 404 included — no new
invoice is cut and the order is put on hold with a note naming the old
invoice.
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish, the plugin name and
Webhook URL in Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* The reconciler compared amounts as strings. The snapshot is written with two
decimals and the server echoes a fiat amount at the currency’s own scale, so a
JPY order (2500.00 against 2500) never matched and the fallback for a lost
webhook skipped it on every run. Amounts are now compared numerically.
* The reconciler re-applied final statuses every ten minutes. Cancelled and
failed orders were fetched and re-noted on each run — thirty cancellations
meant thousands of identical notes and API calls a day — and, sharing one
“newest 50” window with them, an order stuck on hold could fall out of reach.
Orders whose invoice is already final are no longer fetched, an unchanged
status writes nothing, waiting orders get their own window, and an invoice
that was simply not paid yet is no longer described as a rolled-back payment.
* 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.
* Paying again for a failed or re-opened order led to a dead invoice. The
order kept its external_order_id, and the server answers a repeated id with
the same invoice — underpaid, expired or cancelled — so both checkout and
Pay invoice in My Account sent the buyer to a checkout that could no
longer be paid. Such an order now gets a fresh invoice, Pay invoice is
offered only while the invoice is still open, and the invoice deadline is
kept on the order.
* 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.
* A second invoice could be cut while the first could still be paid. Picking a
network moves the invoice deadline on the server (now + PaymentTtl) and
sends no webhook, but the order kept the deadline from creation; once that
passed, paying the order again minted a new external_order_id without asking
the server. The stored id is now always tried first — the server answers it
with the live invoice — and a new invoice is cut only if the server says the
old one ended unpaid or was never started. An invoice the server holds open
(network picked, funds confirming, part paid) is kept, and its status and
deadline are refreshed on the order. A stored id from another environment or
project gets a new one, since the server refuses it there.

1.5.0

• fix(plugins): complete CMS refund release dependencies
• fix(ton): return friendly addresses with existing webhook schema
• fix(woocommerce): refuse offline refunds and refunded status on Paymos orders
• feat(woocommerce): gate native refunds on the connection’s refund capability
• fix(woocommerce): show refund errors on the native button and in the panel
• feat(woocommerce): copy for the native refund panel and its notices
• feat(woocommerce): native refund adapter for full refunds and overpayment notes
• chore: bundle Paymos PHP SDK v1.8.0

• 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.
• Continue reconciliation in later batches after the first 50 orders, so older pending orders also get checked.

Fixed:
* When the checkout could not replace an order’s invoice (BUG-166), the order
note read “Paymos payment amount needs manual review.” although the block
also follows a mode or project change, and the buyer read “Paymos payment
error: unable to create invoice.” (BUG-181). The note is now “Paymos payment
needs manual review.” followed by the SDK’s summary of the old invoice’s
state, and the buyer reads the SDK’s buyer message, “The store needs to
review this order before payment can continue. Please contact the store.”
Both strings are in the .pot and translated in every .po/.mo.
* A changed order could leave its old invoice payable beside the new one
(BUG-166). When the order total, the mode or the project changed, the
checkout cut a new invoice and left the old one open on Paymos, so a buyer
could pay both. The old invoice is now cancelled first, in its own
environment, through the SDK’s InvoiceReplacement; the new one is cut only
after that cancel succeeds or Paymos reports the old one expired, cancelled
or underpaid. When the old invoice is paid, still payable (network picked,
funds confirming, part paid) or cannot be read — a 404 included — no new
invoice is cut and the order is put on hold with a note naming the old
invoice.
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish, the plugin name and
Webhook URL in Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* The reconciler compared amounts as strings. The snapshot is written with two
decimals and the server echoes a fiat amount at the currency’s own scale, so a
JPY order (2500.00 against 2500) never matched and the fallback for a lost
webhook skipped it on every run. Amounts are now compared numerically.
* The reconciler re-applied final statuses every ten minutes. Cancelled and
failed orders were fetched and re-noted on each run — thirty cancellations
meant thousands of identical notes and API calls a day — and, sharing one
“newest 50” window with them, an order stuck on hold could fall out of reach.
Orders whose invoice is already final are no longer fetched, an unchanged
status writes nothing, waiting orders get their own window, and an invoice
that was simply not paid yet is no longer described as a rolled-back payment.
* 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.
* Paying again for a failed or re-opened order led to a dead invoice. The
order kept its external_order_id, and the server answers a repeated id with
the same invoice — underpaid, expired or cancelled — so both checkout and
Pay invoice in My Account sent the buyer to a checkout that could no
longer be paid. Such an order now gets a fresh invoice, Pay invoice is
offered only while the invoice is still open, and the invoice deadline is
kept on the order.
* 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.
* A second invoice could be cut while the first could still be paid. Picking a
network moves the invoice deadline on the server (now + PaymentTtl) and
sends no webhook, but the order kept the deadline from creation; once that
passed, paying the order again minted a new external_order_id without asking
the server. The stored id is now always tried first — the server answers it
with the live invoice — and a new invoice is cut only if the server says the
old one ended unpaid or was never started. An invoice the server holds open
(network picked, funds confirming, part paid) is kept, and its status and
deadline are refreshed on the order. A stored id from another environment or
project gets a new one, since the server refuses it there.

1.4.7

• chore: commit pending Forge records, WordPress packaging and social drafts

• 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.
• Continue reconciliation in later batches after the first 50 orders, so older pending orders also get checked.

Fixed:
* When the checkout could not replace an order’s invoice (BUG-166), the order
note read “Paymos payment amount needs manual review.” although the block
also follows a mode or project change, and the buyer read “Paymos payment
error: unable to create invoice.” (BUG-181). The note is now “Paymos payment
needs manual review.” followed by the SDK’s summary of the old invoice’s
state, and the buyer reads the SDK’s buyer message, “The store needs to
review this order before payment can continue. Please contact the store.”
Both strings are in the .pot and translated in every .po/.mo.
* A changed order could leave its old invoice payable beside the new one
(BUG-166). When the order total, the mode or the project changed, the
checkout cut a new invoice and left the old one open on Paymos, so a buyer
could pay both. The old invoice is now cancelled first, in its own
environment, through the SDK’s InvoiceReplacement; the new one is cut only
after that cancel succeeds or Paymos reports the old one expired, cancelled
or underpaid. When the old invoice is paid, still payable (network picked,
funds confirming, part paid) or cannot be read — a 404 included — no new
invoice is cut and the order is put on hold with a note naming the old
invoice.
* Entries that were present, non-empty and still English — Connect Paymos in
German and Spanish, the plugin name in Turkish, the plugin name and
Webhook URL in Chinese — and one string missing from every catalogue
(in the invoice currency, the fallback in the underpayment notice).
* The reconciler compared amounts as strings. The snapshot is written with two
decimals and the server echoes a fiat amount at the currency’s own scale, so a
JPY order (2500.00 against 2500) never matched and the fallback for a lost
webhook skipped it on every run. Amounts are now compared numerically.
* The reconciler re-applied final statuses every ten minutes. Cancelled and
failed orders were fetched and re-noted on each run — thirty cancellations
meant thousands of identical notes and API calls a day — and, sharing one
“newest 50” window with them, an order stuck on hold could fall out of reach.
Orders whose invoice is already final are no longer fetched, an unchanged
status writes nothing, waiting orders get their own window, and an invoice
that was simply not paid yet is no longer described as a rolled-back payment.
* 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.
* Paying again for a failed or re-opened order led to a dead invoice. The
order kept its external_order_id, and the server answers a repeated id with
the same invoice — underpaid, expired or cancelled — so both checkout and
Pay invoice in My Account sent the buyer to a checkout that could no
longer be paid. Such an order now gets a fresh invoice, Pay invoice is
offered only while the invoice is still open, and the invoice deadline is
kept on the order.
* 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.
* A second invoice could be cut while the first could still be paid. Picking a
network moves the invoice deadline on the server (now + PaymentTtl) and
sends no webhook, but the order kept the deadline from creation; once that
passed, paying the order again minted a new external_order_id without asking
the server. The stored id is now always tried first — the server answers it
with the live invoice — and a new invoice is cut only if the server says the
old one ended unpaid or was never started. An invoice the server holds open
(network picked, funds confirming, part paid) is kept, and its status and
deadline are refreshed on the order. A stored id from another environment or
project gets a new one, since the server refuses it there.