Payment methods

The SDK renders the same three rails as the browser widget, and decides which to show from the checkout lookup — not from anything the host passes.

Method	Shown when	How it runs
New card	Always.	A native card field, then `POST /api/v1/mobile/checkout`, confirm on device, 3DS if the issuer asks, then poll.
Saved card	`customerEmail` was supplied and the shopper has stored cards.	One tap. `POST /api/v1/checkout` carries `saved_payment_method_id`; the API creates and confirms the intent off-session, so there is no client secret and no on-device provider step. The poll still decides the outcome.
Pay by bank	The merchant is eligible and `returnUrl` was supplied.	Consent screen, then a server-confirmed checkout returning `redirect_url`, opened in the platform in-app browser (SFSafariViewController / Custom Tab).

Managing saved cards

The Edit Payment Methods screen is built in, backed by DELETE /api/v1/saved-payment-methods/{id} and POST /api/v1/payment-methods/{id}/set-default. A failure there is shown inline and is never allowed to fail the payment.

Pay by bank settles asynchronously. The shopper coming back from their bank proves nothing — approval reaches RezolvePay by webhook, not by redirect. Never treat the return as success; only the polled status is authoritative. A shopper who abandons the bank page ends in needsReconciliation, never in a false success.