1.9.0

• Store API for headless front ends, second part. check carries hash once a payment is on record:
  the payment page's success view shows the transaction with its explorer link — it had a row for that
  since 1.4.0, which no platform ever filled — and a front end's order page can show it too
• POST /store-api/ledger-direct/payment/refresh/{orderId}: a current quote, re-quoting an order whose
  quote has expired — the "quote expired" button of a front end's payment page. An order with a payment on
  record, short or in the wrong asset, gets its current quote back unchanged; account and tag stay the same
  unless the receiving account was changed in between
• quote hands an expired quote out as the page shows it, with page.state expired, instead of
  answering 410 (1.8.0); 410 stays for an order that no longer waits for a payment. A front end builds the
  same expired page as the storefront and refreshes from there
• The three routes are in the Store API's OpenAPI document (/store-api/_info/openapi3.json), with the
  schemas of the quote, the payment page values and the payment status, so API clients can be generated
  from it

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.9.0. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.

1.8.0

• Store API for headless front ends, first part: GET /store-api/ledger-direct/payment/quote/{orderId}
  answers a guest who sends the order's deepLinkCode, the way check always has, instead of
  requiring a logged-in customer. A wrong code and another customer's order get the same 403, an
  order never quoted with LedgerDirect 404, an expired quote or an order that no longer waits for a payment 410 (was 500)
• The quote payload gains page (schema_version 1): every value the payment page is built from,
  for XRP, RLUSD, USDC and the Stellar assets alike — state, seconds left, amounts as the page shows
  them, account, tag or memo, issuer and currency code, the payment request for the QR code, explorer
  base and the wallet-app identifiers. The storefront's own payment page renders from the same value
  set (PaymentPageView), so the two cannot drift apart. The flat fields of quote stay as they were
• The price route is removed; it was a placeholder answering {"todo": "implement"} since the first
  release. What it was meant for, quote answers
• A card "LedgerDirect - External front end" in the configuration, per sales channel, empty by default:
  the URL of the front end's payment page ({orderId}, {deepLinkCode}, {returnUrl}), which
  handle-payment answers instead of the storefront's page, and the URL of its order page
  ({orderId}, {deepLinkCode}), where a payment arriving after the payment token has expired lands.
  Values are inserted URL-encoded; a template without {deepLinkCode} or not an absolute https:// URL (plain http:// only for
  localhost) is refused on save. Nothing changes for a sales channel without the settings
• README: a section "Headless / external front end" on the Store API, the redirect targets and the
  payment page package's headers option
• Payment page package 0.3.0 (the headers option for the poll); the storefront's behaviour is unchanged

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.8.0. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.

1.7.0

• Stellar as the second chain, as a preview (core 0.10): XLM, USDC and EURC payment methods, paid
  by memo id, synced from Horizon, settled under the same rules as on the XRP Ledger. A card
  "LedgerDirect - Stellar (Preview)" in the configuration, off by default; nothing of Stellar shows
  anywhere else until it is switched on. Switching it on creates the Stellar payment methods, which
  appear at checkout once a receiving account is set. Not for production use yet
• An issued Stellar asset (USDC, EURC) is offered at checkout only while the receiving account has a
  trust line to its issuer; without one the payment would fail in the customer's wallet
• The payment page says "Memo ID" instead of "Destination tag" on Stellar, the QR code carries a SEP-7
  payment request, the transaction links to stellar.expert. The browser-wallet section is XRPL-only
  (payment page package 0.2.0)
• The order detail's LedgerDirect card shows the memo id and the stellar.expert link for a Stellar order
• Console commands take --chain XRPL|STELLAR; the price lookup takes --asset
• Two new tables, ledger_direct_stellar_payment and ledger_direct_stellar_memo, created on update

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.7.0. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.

1.6.0

• The configuration is built for more than one chain. The XRP Ledger card gets a switch "Accept
  payments on the XRP Ledger" (on for every installation that has a receiving account configured); a
  second chain gets a card of its own with the same shape. Nothing was renamed, no setting has to be
  entered again
• Payment methods whose chain is switched off, whose receiving account is missing or whose asset is
  disabled no longer appear at checkout. Until now a disabled stablecoin was still offered and failed
  when the customer chose it
• A receiving address is checked the moment it is saved: an address that is not an account on that
  chain is refused with a message; a stray space or line break around a pasted address is removed
• Core 0.10: the payment methods, their assets and the chain's address format come from the core's
  ChainCatalog; the plugin no longer carries its own list. Under the hood one payment handler per
  chain instead of one per asset; the three XRP Ledger payment methods keep their ids, names and
  handler identifiers
• Core 0.10: a payment on the other network — a testnet payment for a mainnet order — never settles
  an order and never shows as a wrong-token payment
• Groundwork for Stellar (XLM, USDC, EURC), which follows in 1.7.0

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.6.0. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.

1.5.2

• Store validation: a migration no longer reads a column name through a Doctrine DBAL class that
  Shopware 6.8 marks as deprecated. No change in behaviour

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.5.2. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.

1.5.1

• Core 0.9: the synced transactions store the CTID in the column tx_ctid instead of ctid, the
  name every LedgerDirect plugin uses from now on (PostgreSQL reserves ctid for a system column).
  A migration renames the column in place on update; nothing changes for customers or merchants
• Core 0.9: a transaction whose CTID is malformed is skipped during sync, and logged, instead of
  being stored truncated

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.5.1. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.

1.5.0

• A LedgerDirect card on the order detail (tab Details, under the transaction card): the payment's
  state, what was quoted (asset, amount, rate, receiving account, destination tag, issuer, quote
  validity), what arrived — naming the other token and its issuer when it was the wrong one —, what is
  still due, and the transaction as a link to the XRPL explorer. Read-only; computed on the server by
  the new admin route /api/_action/ledger-direct/payment-info/{orderTransactionId} (order:read)
• The scheduled task syncs the configured receiving account on every run, so a payment on an order
  the merchant has already cancelled is on record too

Install: upload the zip in the administration (Extensions → My extensions), or composer require hardcastle/ledger-direct-sw6:1.5.0. Requires Shopware 6.6.5+ or 6.7, PHP 8.2+.