A merchant that supplies `redirectURL` and `redirectAutomatically` is asking for its
customer back, and the moment to do that is detection rather than final depth. The
payment is already irreversible from the payer's side, and the merchant's own page is
where an order status belongs. Waiting for the confirmation target instead parks the
customer on a payment page for as long as the coin takes.
Only the classic style acted on those fields, and it held its own copy of the rule. The
standard style had no automatic return at all, and its way back appeared only once the
invoice was confirmed. Both styles now render one shared component, so the rule lives in
one place, and the return appears as soon as the payment is seen. The receipt still
waits for confirmation, because that is when there is a settled payment to describe.
Also ignores the tsbuildinfo a typecheck leaves behind.
Follow-up to the previous commit — page.tsx now passes
default_qr_logo of type "wownero" | "monero" | "none" | "custom" to
this component, but the prop was still typed as the narrower
"monero" | "none" | "custom" set. Next build failed with TS2322.
Widened initialLogo prop + the internal useState + buildInitialState
helper to match.
The checkout UI only redirected when status was 'confirmed' (after all
N confirmations). Now also redirects on 'payment_detected' (0-conf in
mempool). This matches BTCPay's behavior for BTC/LTC where the customer
is redirected to the store immediately on detection.
jwinterm