Fiat contract

MoonPay guest provider

MOONPAY_GUEST owns guest checkout on POST /fiat/next; regular MOONPAY retains customer connection and KYC. Select guest checkout through routingOverrides.providers on a quote (or the ordered providers list on a routing quote). The backend requires explicit client selection and its own enablement switch. A guest quote answers handoff: { provider: "MOONPAY_GUEST" }. Send provider: "MOONPAY_GUEST" on every next request, with no path or customer credentials. After a guest refusal with REQUOTE, omit MOONPAY_GUEST from the next selection so MOONPAY remains available. The separate ./moonpay-guest entry exports its wire types; schemas are exported from the root.

MoonPay connect preparation

Regular MoonPay's connect next action may carry an optional nonempty, unclaimed orderId. A client may use it to prepare a hidden, inert payment surface beside the connection check. This is not authorization to pay: wait for an accepted order response before revealing the surface. For that first order, the client may retain its prepared id even if the response carries a different id. Without the field, retain the existing behavior and wait for order before creating the payment surface.

Publish this additive contract before backend emission and update backend/frontend dependency pins. Older strict contract schemas reject the field; optionality preserves acceptance of older backend responses, not compatibility with old strict validators receiving the new field.