--- title: "Understand payment method settings" description: "Understand which payment methods are available, when customer confirmation is required, and how to use settings safely in checkout." canonical: "https://studio.inttegro.com/guides/understand-payment-method-settings" format: inttegro-machine-docs/v1 language: "Java" sdk_version: "v8.3.0" reader_profile: optional reader_manifest: "https://studio.inttegro.com/machine/java/readers/index.json" reader_identification: "Optional: declare your client only if known and your current-session capabilities; use reader_manifest for supplemental recommendations." preamble_estimated_tokens: 430 model_token_report: "https://studio.inttegro.com/machine/token-report.json" preamble_questions: 5 preamble_source: "curated" recommended_mcp_tools: ["get_integration_guide","check_integration_readiness","get_payment_method_settings"] estimated_tokens: 3913 token_estimate_method: "utf8_bytes_divided_by_4" --- ## Machine preamble **Summary:** Read the current payment-rail configuration before checkout, offer enabled rails only, and honor the confirmation action returned by a payment. ### Five questions #### Q1. Where does checkout get its available rails? Read [Payment method settings](https://studio.inttegro.com/machine/java/api/payment-methods.md#payment-method-settings) for the current configuration. Present only entries that exist and are enabled; do not hard-code the sample rail list into the application. #### Q2. What does confirmation-required mean? It governs whether the customer may need an explicit step before use of a rail; it is not proof that a saved method is verified. Follow the actual order or payment next action, which can be OTP, redirect, or provider prompt. #### Q3. Can a disabled rail still have saved methods? Yes. Disabling a rail does not delete existing saved methods, but new attempts using that rail should not be offered. Refresh cached settings before an important checkout or after configuration changes. #### Q4. Do settings guarantee a particular customer can pay? No. A payment request still validates customer data, method state, market, provider availability, and limits. Use the [Orders reference](https://studio.inttegro.com/machine/java/api/orders.md) to handle the returned action and final payment state. #### Q5. Which MCP call can inspect live configuration? An authenticated client can use [get_payment_method_settings](https://studio.inttegro.com/machine/java/inttegro-mcp/tools.md#get_payment_method_settings) to see enabled and confirmation-gated rails. Treat the returned settings as live configuration, not a promise that every saved method is reusable. ## Document content # Understand payment method settings Payment method settings tell your application which payment rails Inttegro can accept, and whether each rail needs an explicit customer confirmation step before money moves. Use the settings response to shape checkout, saved-payment-method flows, and support tooling. > Mcp Guide Callout is interactive content. Use the canonical page to view it. Use [Payment method settings](https://studio.inttegro.com/machine/java/api/payment-methods.md#payment-method-settings) for the exact endpoint contract. Use this guide to decide what the settings mean for your integration. ## Retrieve the current settings Call [Payment method settings](https://studio.inttegro.com/machine/java/api/payment-methods.md#payment-method-settings) to retrieve your current configuration. **Get payment method settings — POST /payment\_methods/settings** ```java import com.inttegro.Client; public class Example { public static void main(String[] args) throws Exception { var client = new Client(System.getenv("INTTEGRO_API_KEY")); var result = client.paymentMethods().settings(); } } ``` The response returns a [`settings(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) object keyed by payment-method type. ```json { "settings": { "mobile_money": { "type": "mobile_money", "name": "Mobile Money", "description": "Pay with supported mobile money wallets", "enabled": true, "confirms_use": true }, "bank_account": { "type": "bank_account", "name": "Bank Account", "description": "Pay with a supported bank account", "enabled": true, "confirms_use": false }, "card": { "type": "card", "name": "Card", "description": "Pay with a supported card", "enabled": true, "confirms_use": true } } } ``` Only render or offer payment methods that appear in the response and are enabled. Do not hardcode the list of available rails in your frontend. ## How to read each entry | Field | Meaning | | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [`settings(…).mobileMoney(…).type(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) | Stable API identifier for the rail, such as `"mobile_money"`, `"bank_account"`, or `"card"`. | | [`settings(…).mobileMoney(…).name(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) | Human-readable label suitable for checkout and internal tools. | | [`settings(…).mobileMoney(…).description(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) | Short explanation of the rail. Use it as helper text, not as validation logic. | | [`settings(…).mobileMoney(…).enabled(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) | Whether your Inttegro account can use the rail for new payment-method or payment attempts. | | [`settings(…).mobileMoney(…).confirmsUse(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) | Whether Inttegro expects an explicit customer confirmation step before completing use of that rail. | Treat the response as configuration, not a product catalog. It tells you which payment methods are currently available; it does not guarantee that every customer has a reusable method for every enabled rail. ## Enabled versus disabled When [`settings(…).mobileMoney(…).enabled(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) is `true`, you can present that payment rail and send requests that use it. When [`settings(…).mobileMoney(…).enabled(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) is `false`, hide it from checkout and avoid using it in automated payment flows. Existing saved methods are not deleted just because a rail is disabled, but new attempts with that type should be expected to fail. Common reasons a rail may be disabled: - your Inttegro account has not been approved for that rail; - the rail is not supported in your market; - the merchant has intentionally turned it off; - Inttegro or an upstream provider has temporarily paused it. If your UI caches settings, refresh them before important checkout sessions or after an operator changes payment configuration. ## Confirmation requirements [`settings(…).mobileMoney(…).confirmsUse(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) controls customer interaction, not whether a payment method is verified. If [`settings(…).mobileMoney(…).confirmsUse(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) is `true`, design the flow so the customer can complete the required confirmation. Depending on the rail and provider, that may mean OTP entry, a redirect, a provider prompt, or another next action returned by the payment flow. If [`settings(…).mobileMoney(…).confirmsUse(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) is `false`, the rail may be usable without an extra customer step after the payment method has been accepted by Inttegro. Typical defaults are: | Payment rail | Typical confirmation behavior | | ------------ | ------------------------------------------------------------------------------------------------------------------------ | | Mobile money | Usually confirmation-gated because providers often require customer approval for each charge. | | Card | Often confirmation-gated when additional cardholder authentication is required. | | Bank account | Often not confirmation-gated at charge time because authorization is handled through account-ownership or mandate flows. | Do not override this in your client. If the setting says confirmation is required, assume the user must complete the confirmation path returned by the payment or order operation. ## Building checkout from settings A safe checkout flow usually does this: 1. Fetch the current payment method settings. 2. Keep only entries where [`settings(…).mobileMoney(…).enabled(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) is `true`. 3. Render customer-facing choices using [`settings(…).mobileMoney(…).name(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) and [`settings(…).mobileMoney(…).description(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html). 4. When the customer selects a rail, collect the fields required by that rail. 5. If the resulting payment operation returns a confirmation step, keep the customer in the flow until confirmation succeeds or fails. Do not use settings as the only source of validation. The payment operation still validates customer data, payment-method state, country support, provider availability, amount limits, and account eligibility. ## Operational checks Use settings to answer the questions that usually come up during support and rollout work. | Question | Check | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Why is a payment option missing from checkout? | Confirm that its settings entry exists and its [`settings(…).mobileMoney(…).enabled(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) value is `true`. | | Why did a payment require OTP or another step? | Check [`settings(…).mobileMoney(…).confirmsUse(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) for the selected rail and inspect the payment's next action. | | Can this merchant accept mobile money? | Look for a [`settings(…).mobileMoney(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) entry with [`settings(…).mobileMoney(…).enabled(…)`](https://java.inttegro.dev/v8.3.0/com/inttegro/paymentmethods/PaymentMethodSettings.html) set to `true`, then confirm the provider/network required by the customer is supported. | | Can we charge a saved method silently? | Only if the rail is enabled, the method is reusable, and the resulting operation does not require confirmation. | ## Related resources - [Payment methods API reference](https://studio.inttegro.com/machine/java/api/payment-methods.md) - Exact payment-method and settings contracts. - [Accept a payment](https://studio.inttegro.com/machine/java/guides/accept-a-payment.md) - First payment flow with customer confirmation handling. - [Charge repeat customers](https://studio.inttegro.com/machine/java/guides/charge-repeat-customers.md) - Using saved payment methods. - [Orders API reference](https://studio.inttegro.com/machine/java/api/orders.md) - Payment execution through orders.