Payment methods overview
Onerway supports three kinds of payment methods: cards (credit and debit cards from Visa, Mastercard, and other card networks), wallets (Apple Pay, Google Pay), and local payment method options (bank transfers, e-wallets, buy now pay later, and other methods specific to a country or region).
This section is organized by payment method and covers setup, the differences across integration methods, and method-specific flows. The integration flow of each method is described in Checkout integration, Web SDK integration, and Direct API integration; business scenarios such as saved payment methods, subscriptions, and pre-authorization are covered in Scenarios.
Support by integration method
| Payment method | Checkout | Web SDK | Direct API |
|---|---|---|---|
| Cards | The checkout page collects the card details | The SDK form collects the card details | You collect the card details yourself or pay with a card token; PCI DSS required |
| Apple Pay | The checkout page renders the button; domain verification is handled by Onerway | The SDK renders the button on your page; your domain must be verified | You render the button; your domain must be verified; the encrypted token is decrypted by Onerway or by you |
| Google Pay | The checkout page renders the button | The SDK renders the button on your page | You load the Google Pay JS SDK; the encrypted token is decrypted by Onerway or by you |
| Local payment method | The checkout page shows the available methods, or locks to one | The SDK shows the available methods | Submit the local payment method scope in productType with lpmsInfo, then present the redirect, QR code, or context according to actionType |
With Checkout and the Web SDK, wallet tokens and local payment method redirects are handled by the Onerway-hosted page or the SDK, and payment credentials never reach your system. With the Direct API, the parameter differences for wallets and each local payment method are described on the corresponding pages.
Query available payment methods first
Whether a payment method is available depends on your merchant configuration, the customer's country or region, the currency, and the amount; do not decide by currency alone. Before displaying payment methods, call List available payment methods to filter by the current order context, cache the result, and refresh it when your configuration changes. Currency and amount rules are covered in Currency and amount validation.
Wallet records in the result carry the local payment method scope value in productType for classification only; when creating a wallet transaction through the Direct API, always submit productType=CARD with subProductType=DIRECT. Wallet records also return the configuration needed to initialize the wallet on your page: both ApplePay and GooglePay may return countryCode, subCardTypes, gatewayName, and merchantId, while gatewayMerchantId is returned for GooglePay only; see the wallet pages for how to use each value.
Payment method in notifications
The payment result webhook returns the payment method that was actually charged in paymentMethod, and wallet transactions may additionally return walletTypeName. Which of the two carries which level of detail varies by wallet, so read both when you need to identify the payment method; walletTypeName has a documented value list, while paymentMethod reflects the channel that was actually charged and is not a closed set. Signature verification, acknowledgement, and status interpretation are covered in Webhooks.
Direct API integration
Submit card data or tokens directly from your server through the create direct transaction API, handle 3DS redirects yourself, and rely on webhooks for the final results of payments, tokenization, subscriptions, and pre-authorizations.
Apple Pay
How Apple Pay differs across Checkout, Web SDK, and Direct API, domain verification and account setup, the Direct API session flow and token submission, wallet subscriptions, and common issues.