This repository contains two published packages:

• packages/taler-merchant — a client for the GNU Taler merchant backend API
• packages/medusa-payment-taler — a MedusaJS v2 payment provider built on it

apps/backend and apps/storefront are a demonstration deployment, not supported software. Vulnerabilities that only affect the demo apps are still welcome, but are triaged below the packages.

Vulnerabilities in GNU Taler itself (exchange, merchant backend, wallet) belong upstream at https://taler.net, not here. Vulnerabilities in MedusaJS belong with the Medusa project.

Report privately through GitHub's "Report a vulnerability" form on this repository. That opens a private advisory visible only to the maintainer.

Please do not open a public issue for a suspected vulnerability first.

Include, as far as you can: affected package and version, the deployment shape (self-hosted Medusa version, GNU Taler merchant backend version), reproduction steps, and what an attacker gains.

Expect an acknowledgement within 7 days. This is a single-maintainer project, so please allow reasonable time for a fix before public disclosure; 90 days is the default assumption and can be shortened by agreement if a fix lands sooner.

Pre-1.0. Only the latest published version of each package receives fixes.

What the packages assume, and what they deliberately do not do:

• The merchant backend is the only authority on payment state. Order status is read from the backend. A webhook payload, a client-supplied claim, or cached session data is never sufficient to mark a payment paid.
• Webhook payloads are untrusted wake-up signals. Receiving one triggers a re-read of authoritative state; it never carries the state itself.
• Payment state does not regress. A monotonic status rank discards duplicate, delayed, and out-of-order reads, so a replayed event cannot move a paid session back to unpaid or trigger a cancel/recreate of a paid order.
• The merchant access token is server-side only. It is passed to the provider through Medusa module options and sent only to the configured merchant backend as an RFC 8959 secret-token: bearer credential. Payment session data returned toward the storefront carries the Taler order id, the per-order claim token, the amount, and the taler:// pay URI — never the merchant credential. The claim token is scoped to a single order by design, since the wallet needs it to claim that order. Deployments must keep the merchant token in environment configuration and out of client bundles.
• No secrets are logged. Errors carry the HTTP status and the Taler error body, not the credential.
• No exchange, wallet, or KYC functionality. These packages speak the merchant protocol and hold no funds.

Neither package has runtime dependencies beyond the other, which keeps the supply-chain surface to Node itself.

Documented rather than hidden. These are proof-of-concept gaps, not accepted risks for production use:

• Refund translation from Medusa increments to Taler cumulative totals reads the order's current refunded amount first. Concurrent refunds on one order are not serialised by the provider; a lock belongs in the funded hardening work.
• Webhook registration (ensureTalerWebhooks) does not yet verify a signature on inbound calls, which is why payloads are treated as untrusted and re-verified. Do not grant webhook endpoints any authority.
• The demo apps ship development defaults and are not hardened for public deployment.