Paymos Stablecoin Checkout for WooCommerce supports Sandbox and Live payments, HMAC-signed Merchant API requests, authenticated webhooks, event deduplication, reconciliation, HPOS, and Checkout Blocks.<\/p>\n\n
The official package contains no merchant secrets. Connect it from WooCommerce settings using the one-time Paymos device approval flow. Credentials are encrypted with AES-256-GCM using WordPress installation security salts and are never rendered back into the settings page.<\/p>\n\n
This plugin connects your WooCommerce store to Paymos. Click Connect Paymos<\/strong> in the store admin to begin. The plugin starts the device flow at The plugin calls Buyers open the hosted payment page at Read the Paymos Terms<\/a> and Privacy Policy<\/a> before connecting.<\/p>\n\n\n No. Official release packages are identical for every merchant and contain no merchant credentials.<\/p><\/dd>\n In a non-autoloaded WordPress option encrypted with AES-256-GCM. Key material is derived from this WordPress installation's security salts.<\/p><\/dd>\n The project currently selected in Paymos when you approve the connection. There is no second project selector.<\/p><\/dd>\n No. OAuth device authorization is only a one-time credential delivery channel. Runtime Merchant API calls remain HMAC signed.<\/p><\/dd>\n\n<\/dl>\n\n\n 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* When the checkout could not replace an order's invoice (BUG-166), the order\n note read \"Paymos payment amount needs manual review.\" although the block\n also follows a mode or project change, and the buyer read \"Paymos payment\n error: unable to create invoice.\" (BUG-181). The note is now \"Paymos payment\n needs manual review.\" followed by the SDK's summary of the old invoice's\n state, and the buyer reads the SDK's buyer message, \"The store needs to\n review this order before payment can continue. Please contact the store.\"\n Both strings are in the fix(plugins): reject invalid Woo refund controls and unblock SDK checks<\/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* When the checkout could not replace an order's invoice (BUG-166), the order\n note read \"Paymos payment amount needs manual review.\" although the block\n also follows a mode or project change, and the buyer read \"Paymos payment\n error: unable to create invoice.\" (BUG-181). The note is now \"Paymos payment\n needs manual review.\" followed by the SDK's summary of the old invoice's\n state, and the buyer reads the SDK's buyer message, \"The store needs to\n review this order before payment can continue. Please contact the store.\"\n Both strings are in the fix(plugins): require helper-complete PHP SDK for refunds<\/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* When the checkout could not replace an order's invoice (BUG-166), the order\n note read \"Paymos payment amount needs manual review.\" although the block\n also follows a mode or project change, and the buyer read \"Paymos payment\n error: unable to create invoice.\" (BUG-181). The note is now \"Paymos payment\n needs manual review.\" followed by the SDK's summary of the old invoice's\n state, and the buyer reads the SDK's buyer message, \"The store needs to\n review this order before payment can continue. Please contact the store.\"\n Both strings are in the 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* When the checkout could not replace an order's invoice (BUG-166), the order\n note read \"Paymos payment amount needs manual review.\" although the block\n also follows a mode or project change, and the buyer read \"Paymos payment\n error: unable to create invoice.\" (BUG-181). The note is now \"Paymos payment\n needs manual review.\" followed by the SDK's summary of the old invoice's\n state, and the buyer reads the SDK's buyer message, \"The store needs to\n review this order before payment can continue. Please contact the store.\"\n Both strings are in the 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* When the checkout could not replace an order's invoice (BUG-166), the order\n note read \"Paymos payment amount needs manual review.\" although the block\n also follows a mode or project change, and the buyer read \"Paymos payment\n error: unable to create invoice.\" (BUG-181). The note is now \"Paymos payment\n needs manual review.\" followed by the SDK's summary of the old invoice's\n state, and the buyer reads the SDK's buyer message, \"The store needs to\n review this order before payment can continue. Please contact the store.\"\n Both strings are in the https:\/\/app.paymos.io\/connect\/cms\/device<\/code> and polls https:\/\/app.paymos.io\/connect\/token<\/code>. Your browser opens the Paymos approval page with the plugin identifier, store origin, admin return URL, and user_code<\/code>. The secret device_code<\/code> goes from the plugin to the token endpoint. After approval, the plugin stores Sandbox and Live credentials in WordPress options encrypted with AES-256-GCM, then discards the short-lived OAuth token.<\/p>\n\nhttps:\/\/api.paymos.io\/v1\/invoices<\/code> to create invoices, GET \/v1\/invoices\/{invoice_id}<\/code> to check status, and POST \/v1\/invoices\/{invoice_id}\/cancel<\/code> to cancel them. Requests carry a key ID, timestamp, and HMAC signature; the API secret signs requests locally. Invoice data includes project_id<\/code>, amount<\/code>, currency<\/code>, and external_order_id<\/code>, plus the native customer ID as client_id<\/code> when available. The WooCommerce order reference includes the order access key.<\/p>\n\nhttps:\/\/checkout.paymos.io<\/code> over HTTPS. Paymos sends signed invoice and payment webhooks back to your store so the plugin can update the order.<\/p>\n\n\n
\n
Does the plugin ZIP contain my API secrets?<\/h3><\/dt>\n
Where are credentials stored?<\/h3><\/dt>\n
Which project is connected?<\/h3><\/dt>\n
Does OAuth replace Merchant API HMAC authentication?<\/h3><\/dt>\n
1.5.3<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\n.pot<\/code> and translated in every .po<\/code>\/.mo<\/code>.\n* A changed order could leave its old invoice payable beside the new one\n (BUG-166). When the order total, the mode or the project changed, the\n checkout cut a new invoice and left the old one open on Paymos, so a buyer\n could pay both. The old invoice is now cancelled first, in its own\n environment, through the SDK's InvoiceReplacement<\/code>; the new one is cut only\n after that cancel succeeds or Paymos reports the old one expired, cancelled\n or underpaid. When the old invoice is paid, still payable (network picked,\n funds confirming, part paid) or cannot be read \u2014 a 404 included \u2014 no new\n invoice is cut and the order is put on hold with a note naming the old\n invoice.\n* Entries that were present, non-empty and still English \u2014 Connect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish, the plugin name and\n Webhook URL in Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* The reconciler compared amounts as strings. The snapshot is written with two\n decimals and the server echoes a fiat amount at the currency's own scale, so a\n JPY order (2500.00<\/code> against 2500<\/code>) never matched and the fallback for a lost\n webhook skipped it on every run. Amounts are now compared numerically.\n* The reconciler re-applied final statuses every ten minutes. Cancelled and\n failed orders were fetched and re-noted on each run \u2014 thirty cancellations\n meant thousands of identical notes and API calls a day \u2014 and, sharing one\n \"newest 50\" window with them, an order stuck on hold could fall out of reach.\n Orders whose invoice is already final are no longer fetched, an unchanged\n status writes nothing, waiting orders get their own window, and an invoice\n that was simply not paid yet is no longer described as a rolled-back payment.\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* Paying again for a failed or re-opened order led to a dead invoice. The\n order kept its external_order_id<\/code>, and the server answers a repeated id with\n the same invoice \u2014 underpaid, expired or cancelled \u2014 so both checkout and\n Pay invoice<\/strong> in My Account sent the buyer to a checkout that could no\n longer be paid. Such an order now gets a fresh invoice, Pay invoice<\/strong> is\n offered only while the invoice is still open, and the invoice deadline is\n kept on the order.\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.\n* A second invoice could be cut while the first could still be paid. Picking a\n network moves the invoice deadline on the server (now + PaymentTtl<\/code>) and\n sends no webhook, but the order kept the deadline from creation; once that\n passed, paying the order again minted a new external_order_id<\/code> without asking\n the server. The stored id is now always tried first \u2014 the server answers it\n with the live invoice \u2014 and a new invoice is cut only if the server says the\n old one ended unpaid or was never started. An invoice the server holds open\n (network picked, funds confirming, part paid) is kept, and its status and\n deadline are refreshed on the order. A stored id from another environment or\n project gets a new one, since the server refuses it there.<\/p>\n\n1.5.2<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\n.pot<\/code> and translated in every .po<\/code>\/.mo<\/code>.\n* A changed order could leave its old invoice payable beside the new one\n (BUG-166). When the order total, the mode or the project changed, the\n checkout cut a new invoice and left the old one open on Paymos, so a buyer\n could pay both. The old invoice is now cancelled first, in its own\n environment, through the SDK's InvoiceReplacement<\/code>; the new one is cut only\n after that cancel succeeds or Paymos reports the old one expired, cancelled\n or underpaid. When the old invoice is paid, still payable (network picked,\n funds confirming, part paid) or cannot be read \u2014 a 404 included \u2014 no new\n invoice is cut and the order is put on hold with a note naming the old\n invoice.\n* Entries that were present, non-empty and still English \u2014 Connect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish, the plugin name and\n Webhook URL in Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* The reconciler compared amounts as strings. The snapshot is written with two\n decimals and the server echoes a fiat amount at the currency's own scale, so a\n JPY order (2500.00<\/code> against 2500<\/code>) never matched and the fallback for a lost\n webhook skipped it on every run. Amounts are now compared numerically.\n* The reconciler re-applied final statuses every ten minutes. Cancelled and\n failed orders were fetched and re-noted on each run \u2014 thirty cancellations\n meant thousands of identical notes and API calls a day \u2014 and, sharing one\n \"newest 50\" window with them, an order stuck on hold could fall out of reach.\n Orders whose invoice is already final are no longer fetched, an unchanged\n status writes nothing, waiting orders get their own window, and an invoice\n that was simply not paid yet is no longer described as a rolled-back payment.\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* Paying again for a failed or re-opened order led to a dead invoice. The\n order kept its external_order_id<\/code>, and the server answers a repeated id with\n the same invoice \u2014 underpaid, expired or cancelled \u2014 so both checkout and\n Pay invoice<\/strong> in My Account sent the buyer to a checkout that could no\n longer be paid. Such an order now gets a fresh invoice, Pay invoice<\/strong> is\n offered only while the invoice is still open, and the invoice deadline is\n kept on the order.\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.\n* A second invoice could be cut while the first could still be paid. Picking a\n network moves the invoice deadline on the server (now + PaymentTtl<\/code>) and\n sends no webhook, but the order kept the deadline from creation; once that\n passed, paying the order again minted a new external_order_id<\/code> without asking\n the server. The stored id is now always tried first \u2014 the server answers it\n with the live invoice \u2014 and a new invoice is cut only if the server says the\n old one ended unpaid or was never started. An invoice the server holds open\n (network picked, funds confirming, part paid) is kept, and its status and\n deadline are refreshed on the order. A stored id from another environment or\n project gets a new one, since the server refuses it there.<\/p>\n\n1.5.1<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\n.pot<\/code> and translated in every .po<\/code>\/.mo<\/code>.\n* A changed order could leave its old invoice payable beside the new one\n (BUG-166). When the order total, the mode or the project changed, the\n checkout cut a new invoice and left the old one open on Paymos, so a buyer\n could pay both. The old invoice is now cancelled first, in its own\n environment, through the SDK's InvoiceReplacement<\/code>; the new one is cut only\n after that cancel succeeds or Paymos reports the old one expired, cancelled\n or underpaid. When the old invoice is paid, still payable (network picked,\n funds confirming, part paid) or cannot be read \u2014 a 404 included \u2014 no new\n invoice is cut and the order is put on hold with a note naming the old\n invoice.\n* Entries that were present, non-empty and still English \u2014 Connect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish, the plugin name and\n Webhook URL in Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* The reconciler compared amounts as strings. The snapshot is written with two\n decimals and the server echoes a fiat amount at the currency's own scale, so a\n JPY order (2500.00<\/code> against 2500<\/code>) never matched and the fallback for a lost\n webhook skipped it on every run. Amounts are now compared numerically.\n* The reconciler re-applied final statuses every ten minutes. Cancelled and\n failed orders were fetched and re-noted on each run \u2014 thirty cancellations\n meant thousands of identical notes and API calls a day \u2014 and, sharing one\n \"newest 50\" window with them, an order stuck on hold could fall out of reach.\n Orders whose invoice is already final are no longer fetched, an unchanged\n status writes nothing, waiting orders get their own window, and an invoice\n that was simply not paid yet is no longer described as a rolled-back payment.\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* Paying again for a failed or re-opened order led to a dead invoice. The\n order kept its external_order_id<\/code>, and the server answers a repeated id with\n the same invoice \u2014 underpaid, expired or cancelled \u2014 so both checkout and\n Pay invoice<\/strong> in My Account sent the buyer to a checkout that could no\n longer be paid. Such an order now gets a fresh invoice, Pay invoice<\/strong> is\n offered only while the invoice is still open, and the invoice deadline is\n kept on the order.\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.\n* A second invoice could be cut while the first could still be paid. Picking a\n network moves the invoice deadline on the server (now + PaymentTtl<\/code>) and\n sends no webhook, but the order kept the deadline from creation; once that\n passed, paying the order again minted a new external_order_id<\/code> without asking\n the server. The stored id is now always tried first \u2014 the server answers it\n with the live invoice \u2014 and a new invoice is cut only if the server says the\n old one ended unpaid or was never started. An invoice the server holds open\n (network picked, funds confirming, part paid) is kept, and its status and\n deadline are refreshed on the order. A stored id from another environment or\n project gets a new one, since the server refuses it there.<\/p>\n\n1.5.0<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\n.pot<\/code> and translated in every .po<\/code>\/.mo<\/code>.\n* A changed order could leave its old invoice payable beside the new one\n (BUG-166). When the order total, the mode or the project changed, the\n checkout cut a new invoice and left the old one open on Paymos, so a buyer\n could pay both. The old invoice is now cancelled first, in its own\n environment, through the SDK's InvoiceReplacement<\/code>; the new one is cut only\n after that cancel succeeds or Paymos reports the old one expired, cancelled\n or underpaid. When the old invoice is paid, still payable (network picked,\n funds confirming, part paid) or cannot be read \u2014 a 404 included \u2014 no new\n invoice is cut and the order is put on hold with a note naming the old\n invoice.\n* Entries that were present, non-empty and still English \u2014 Connect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish, the plugin name and\n Webhook URL in Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* The reconciler compared amounts as strings. The snapshot is written with two\n decimals and the server echoes a fiat amount at the currency's own scale, so a\n JPY order (2500.00<\/code> against 2500<\/code>) never matched and the fallback for a lost\n webhook skipped it on every run. Amounts are now compared numerically.\n* The reconciler re-applied final statuses every ten minutes. Cancelled and\n failed orders were fetched and re-noted on each run \u2014 thirty cancellations\n meant thousands of identical notes and API calls a day \u2014 and, sharing one\n \"newest 50\" window with them, an order stuck on hold could fall out of reach.\n Orders whose invoice is already final are no longer fetched, an unchanged\n status writes nothing, waiting orders get their own window, and an invoice\n that was simply not paid yet is no longer described as a rolled-back payment.\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* Paying again for a failed or re-opened order led to a dead invoice. The\n order kept its external_order_id<\/code>, and the server answers a repeated id with\n the same invoice \u2014 underpaid, expired or cancelled \u2014 so both checkout and\n Pay invoice<\/strong> in My Account sent the buyer to a checkout that could no\n longer be paid. Such an order now gets a fresh invoice, Pay invoice<\/strong> is\n offered only while the invoice is still open, and the invoice deadline is\n kept on the order.\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.\n* A second invoice could be cut while the first could still be paid. Picking a\n network moves the invoice deadline on the server (now + PaymentTtl<\/code>) and\n sends no webhook, but the order kept the deadline from creation; once that\n passed, paying the order again minted a new external_order_id<\/code> without asking\n the server. The stored id is now always tried first \u2014 the server answers it\n with the live invoice \u2014 and a new invoice is cut only if the server says the\n old one ended unpaid or was never started. An invoice the server holds open\n (network picked, funds confirming, part paid) is kept, and its status and\n deadline are refreshed on the order. A stored id from another environment or\n project gets a new one, since the server refuses it there.<\/p>\n\n1.4.7<\/h4>\n\n
\n
false<\/code> from save or status updates.<\/li>\n.pot<\/code> and translated in every .po<\/code>\/.mo<\/code>.\n* A changed order could leave its old invoice payable beside the new one\n (BUG-166). When the order total, the mode or the project changed, the\n checkout cut a new invoice and left the old one open on Paymos, so a buyer\n could pay both. The old invoice is now cancelled first, in its own\n environment, through the SDK's InvoiceReplacement<\/code>; the new one is cut only\n after that cancel succeeds or Paymos reports the old one expired, cancelled\n or underpaid. When the old invoice is paid, still payable (network picked,\n funds confirming, part paid) or cannot be read \u2014 a 404 included \u2014 no new\n invoice is cut and the order is put on hold with a note naming the old\n invoice.\n* Entries that were present, non-empty and still English \u2014 Connect Paymos<\/code> in\n German and Spanish, the plugin name in Turkish, the plugin name and\n Webhook URL in Chinese \u2014 and one string missing from every catalogue\n (in the invoice currency<\/code>, the fallback in the underpayment notice).\n* The reconciler compared amounts as strings. The snapshot is written with two\n decimals and the server echoes a fiat amount at the currency's own scale, so a\n JPY order (2500.00<\/code> against 2500<\/code>) never matched and the fallback for a lost\n webhook skipped it on every run. Amounts are now compared numerically.\n* The reconciler re-applied final statuses every ten minutes. Cancelled and\n failed orders were fetched and re-noted on each run \u2014 thirty cancellations\n meant thousands of identical notes and API calls a day \u2014 and, sharing one\n \"newest 50\" window with them, an order stuck on hold could fall out of reach.\n Orders whose invoice is already final are no longer fetched, an unchanged\n status writes nothing, waiting orders get their own window, and an invoice\n that was simply not paid yet is no longer described as a rolled-back payment.\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* Paying again for a failed or re-opened order led to a dead invoice. The\n order kept its external_order_id<\/code>, and the server answers a repeated id with\n the same invoice \u2014 underpaid, expired or cancelled \u2014 so both checkout and\n Pay invoice<\/strong> in My Account sent the buyer to a checkout that could no\n longer be paid. Such an order now gets a fresh invoice, Pay invoice<\/strong> is\n offered only while the invoice is still open, and the invoice deadline is\n kept on the order.\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.\n* A second invoice could be cut while the first could still be paid. Picking a\n network moves the invoice deadline on the server (now + PaymentTtl<\/code>) and\n sends no webhook, but the order kept the deadline from creation; once that\n passed, paying the order again minted a new external_order_id<\/code> without asking\n the server. The stored id is now always tried first \u2014 the server answers it\n with the live invoice \u2014 and a new invoice is cut only if the server says the\n old one ended unpaid or was never started. An invoice the server holds open\n (network picked, funds confirming, part paid) is kept, and its status and\n deadline are refreshed on the order. A stored id from another environment or\n project gets a new one, since the server refuses it there.<\/p>","raw_excerpt":"Accept stablecoin payments with Paymos hosted checkout and signed webhooks.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/393378","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=393378"}],"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=393378"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=393378"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=393378"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=393378"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=393378"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=393378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}