Develop a payment module and hosted checkout

Required methods and data

Implement PaymentModule::supportsCurrency, startCheckout and verifyWebhook together with the integration schema/Test. Checkout context carries attempt UUID, invoice public ID/number, exact positive integer minor amount, currency, customer email, generated return/webhook URLs and, in the newer matching core, real payer billing data. Return CheckoutResult with the actual provider external ID and verified HTTPS destination.

Reserve and commit the checkout before provider I/O through the existing core. Send the attempt UUID as provider idempotency/reference where supported. Never automatically retry an uncertain payment-creation POST. Do not invent a second dispatcher or put card/CVC forms into the billing application.

Verification contract

WebhookContext contains the original raw body, headers, HTTP method and URL. Verify the provider's exact signature/account/environment/freshness scheme before accepting or intentionally ignoring an event. Require final settled/captured funds, exact amount/currency, original attempt and external checkout identity. Return stable event and settlement references through VerifiedPayment; include the extended checkout binding supported by the matching release. Null is not a reason to bless an unauthenticated claim.

The core then checks its stored invoice/attempt/connection and allocates the ledger idempotently. Modules must not write PaymentEntry directly to bypass those guards. Refunds, disputes, card storage and subscription charging are separate features, not implicit PaymentModule behavior.

Optional newer behavior

Use ConnectionCurrencySupport for account-specific currencies and CheckoutRequirements for real billing fields (name, first/last name, phone, street/address, city, state, country, postal code or network address as permitted). Missing data stops before provider submission; do not fabricate a phone/country.

Use only the installed contracts for signed returns, allowed locator parameters, authenticated hosted bridges/forms, method discovery, fully verified batches, provider acknowledgements and GET endpoint challenges. Hosted form tokens are stored/reused durably for the same attempt; reload must not create another payable session. Browser return is never itself settlement proof.

Required tests

Cover declined/pending/authorised/partial/refunded versus settled states, wrong merchant/currency/amount/reference, duplicate and conflicting callbacks, expired return context, uncertain POST, handoff reload, revoked connection, missing payer fields and safe diagnostics. Merchant sandbox end-to-end acceptance remains necessary after local mocked tests pass.