# eCommerce Checkout Payment Methods

## Responsibility split

The storefront payment configuration deliberately separates provider connectivity from checkout presentation.

1. **Payment Core → Providers & API** connects Stripe, PayPal, Adyen, Checkout.com, Worldpay, Razorpay, Mollie or a buyer-defined adapter. Merchant/API credentials, hosted payment-session creation and webhook verification belong to the buyer backend and provider integration.
2. **Payment Core → Payment Methods** describes the central capability catalog and market/provider eligibility.
3. **eCommerce → Checkout → Payment Methods** decides what the customer sees for a particular storefront: enabled state, display order, icon/logo, customer-facing title/description, country/currency/order rules and offline-method instructions.
4. **Buyer backend** creates provider sessions, validates amount/currency/order ownership, verifies signed callbacks, deduplicates events and confirms the final payment state.

## Checkout resolution

A storefront method should render only when all applicable gates pass:

`Provider connected → Merchant enabled → Market eligible → Order eligible → Customer presented`

Payment success remains backend/provider-event confirmed. A browser redirect or UI success screen is not authoritative payment evidence.

## Adding methods

The merchant can add a known capability from the catalog or create a custom method. A custom method can be:

- provider/gateway/wallet backed,
- direct bank transfer,
- Cash on Delivery.

New provider methods begin disabled until the Payment Core connection is ready. Bank transfer and COD can operate as manual/offline rails without pretending that a gateway API exists.

## Icons and logos

Every checkout method has a built-in fallback icon. Merchants can also select a clean image from the shared Media Library, upload a new asset through Media Library, or reference a buyer-owned asset path. The customer preview uses the same identity asset as the method-order list.

## PayPal

PayPal Checkout remains provider-backed. The checkout profile can store a non-secret merchant account email and merchant/app reference so operators know which business account the storefront belongs to. PayPal client IDs, client secrets, OAuth tokens and webhook verification remain in Payment Core and the buyer backend.

## Direct bank transfer

Direct bank transfer is an offline/manual checkout rail. The merchant can configure:

- bank name and country,
- branch name and bank/branch address,
- account holder / beneficiary,
- beneficiary address,
- account number,
- routing/ABA number,
- sort code,
- SWIFT/BIC,
- IBAN / international routing details,
- customer payment instructions.

Sensitive bank configuration should be stored and served according to the buyer backend's security policy rather than browser storage.

## Cash on Delivery

COD can be enabled without a gateway API. Typical eligibility includes country/shipping zone, physical fulfillment, minimum/maximum order value, handling fee and optional product/category restrictions. COD collection and courier settlement reconcile through Logistics and Finance rather than being marked as an online provider authorization.

## Theme/template boundary

This frontend template illustrates configuration and operational UX only. It does not store raw card/CVV data, provider secrets, refresh tokens or production banking secrets, and it does not pretend a client-side click is a completed payment.