The official package contains no merchant credentials. Open Downloads -> Settings -> Payments -> Paymos and click Connect Paymos. Approve the current project in Paymos; the plugin receives Sandbox and Live credentials once, stores them in an AES-256-GCM encrypted WordPress option, and discards the short-lived OAuth token.<\/p>\n\n
Runtime Merchant API requests remain HMAC signed. Signed webhooks update invoices without a local invoice reconciliation job: a delivery that fails is retried by Paymos across roughly 16 hours, and anything that outlives the ladder is replayed from the Paymos dashboard. Pending refunds are reconciled locally by a 1-minute WP-Cron job ( Paymos handles payment requests for this Easy Digital Downloads gateway. To connect, click Connect Paymos<\/strong> in your WordPress admin and approve the connection in Paymos. Device authorization starts at For payments, the plugin creates invoices at For refunds, the plugin sends Buyers pay over HTTPS at No. Every merchant downloads the same public package.<\/p><\/dd>\n In a non-autoloaded WordPress option encrypted with AES-256-GCM using installation security salts.<\/p><\/dd>\n\n<\/dl>\n\n\n chore: bundle Paymos PHP SDK v1.9.1<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 chore: rebuild canonical CMS package<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 chore: bundle Paymos PHP SDK v1.8.1<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 chore: rebuild canonical CMS package<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 fix(edd): validate refund controls and prepare directory database queries<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 fix(plugins): require helper-complete PHP SDK for refunds<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 chore: rebuild canonical CMS package<\/p><\/li>\n Moved optional Paymos diagnostics from PHP error_log to the EDD debug log, with masking for supported key patterns. Logging remains off by default.<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 chore: rebuild canonical CMS package<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 chore: rebuild canonical CMS package<\/p><\/li>\n Compare amounts as exact decimals and require complete invoice snapshots plus API confirmation before changing payment state.<\/p><\/li>\n Fixed:\n* Entries that were present, non-empty and still English \u2014 paymos_edd_refunds_reconcile<\/code>).<\/p>\n\nExternal services<\/h3>\n\n
https:\/\/app.paymos.io\/connect\/cms\/device<\/code>; the plugin polls https:\/\/app.paymos.io\/connect\/token<\/code> for approval. The browser approval URL carries the plugin identifier, store origin, admin return URL, and user_code<\/code>. The plugin sends the secret device_code<\/code> to the token endpoint. It stores the returned Sandbox and Live credentials in AES-256-GCM-encrypted WordPress options and discards the short-lived OAuth token.<\/p>\n\nhttps:\/\/api.paymos.io\/v1\/invoices<\/code>, checks them with GET \/v1\/invoices\/{invoice_id}<\/code>, and cancels them with POST \/v1\/invoices\/{invoice_id}\/cancel<\/code>. Each signed request sends a key ID, timestamp, and HMAC signature. The API secret stays with the plugin for signing. Invoice fields include project_id<\/code>, amount<\/code>, currency<\/code>, external_order_id<\/code>, and, when available, the native customer ID as client_id<\/code>. New orders use a random opaque reference. Existing references remain in use and can contain an EDD purchase key.<\/p>\n\nPOST \/v1\/refunds<\/code> requests to https:\/\/api.paymos.io\/v1\/refunds<\/code> with only invoice_id<\/code>, mode<\/code> (full<\/code> or overpayment<\/code>), and external_order_id<\/code>; Paymos returns funds strictly to the verified first_sender<\/code> address recorded on the invoice. The plugin checks individual refund status with GET \/v1\/refunds\/{refund_id}<\/code>, polls cursor-paginated refund pages with GET \/v1\/refunds<\/code> (cursor<\/code>, limit<\/code>, invoice_id<\/code>, and status<\/code>), and in Sandbox mode simulates terminal outcomes with POST \/v1\/sandbox\/refunds\/{refund_id}\/simulate<\/code> sending status<\/code> (completed<\/code>, failed<\/code>, or cancelled<\/code>). Pending refunds are polled by a 1-minute WP-Cron job (paymos_edd_refunds_reconcile<\/code>).<\/p>\n\nhttps:\/\/checkout.paymos.io<\/code>. Signed invoice and payment webhooks return to the store to update orders. Service terms and data handling appear in the Terms<\/a> and Privacy Policy<\/a>.<\/p>\n\n\n\n
\n
Does the ZIP contain secrets?<\/h3><\/dt>\n
Where are credentials stored?<\/h3><\/dt>\n
1.6.2<\/h4>\n\n
\n
1.6.1<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.6.0<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.5.4<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.5.3<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.5.2<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.5.1<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.5.0<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.4.10<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>\n\n1.4.9<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\nConnect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish and Chinese, Webhook URL<\/code> in\n Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* A late non-final webhook could reopen a finished order. Webhooks are\n delivered at least once and in no particular order, and only paid orders were\n guarded: an invoice.underpaid_waiting<\/code> or invoice.confirming<\/code> arriving after\n the invoice had already ended underpaid, expired or cancelled moved the order\n back into an open state. Nothing leaves a final status on the server, so once\n one is recorded for an invoice every later event for it is ignored and the\n final status stays recorded.\n* A new invoice now resets the Paymos status recorded on the payment, so an\n event for it is never taken for a stale one after an earlier final status.\n* A webhook retry that arrived while the first delivery was still being\n processed was answered 200 \"duplicate\". Paymos gives a delivery 10 seconds and\n retries, while a slow reverse-verification call can take longer; the retry was\n acknowledged as delivered, and if the first attempt then failed the event was\n lost. An event that is only locked, not yet committed, is now answered 409 so\n Paymos tries again, and the lock the first delivery holds is left alone.<\/p>","raw_excerpt":"Accept stablecoin payments in Easy Digital Downloads with Paymos hosted checkout.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/396265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=396265"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/paymos"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=396265"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=396265"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=396265"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=396265"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=396265"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=396265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}