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.

Use MCP to inspect payment-method settings

An authenticated AI agent can fetch the current payment-method configuration and summarize which rails are enabled, disabled, or confirmation-gated.

MCP tools: get_payment_method_settings

Use 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_methods/settings to retrieve your current configuration.

Get payment method settings

POST/payment_methods/settings

cURL

curl https://api.inttegro.com/payment_methods/settings \
  -H "Authorization: Bearer $INTTEGRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

TypeScript

SDK versionv8.2.0

import * as Inttegro from '@inttegro/inttegro-sdk'

const inttegro = new Inttegro.InttegroClient({
  apiKey: process.env.INTTEGRO_API_KEY!,
})
const result = await inttegro.paymentMethods.settings()

Go

SDK versionv4.4.0

package main

import (
  "context"
  "log"
  "os"

  inttegro "github.com/zebodotdev/inttegro-sdk-go/v4"
)

func main() {
  ctx := context.Background()
  client := inttegro.NewClient(os.Getenv("INTTEGRO_API_KEY"))

  result, err := client.PaymentMethods.Settings(ctx)
  if err != nil {
    log.Fatal(err)
  }
  _ = result
}

Python

SDK versionv6.2.0

import os
import inttegro

client = inttegro.InttegroClient(api_key=os.environ["INTTEGRO_API_KEY"])
result = client.payment_methods.settings()

PHP

SDK versionv5.3.0

<?php

use Inttegro\Client;

$client = new Client($_ENV['INTTEGRO_API_KEY']);
$result = $client->paymentMethods->settings();

Ruby

SDK versionv4.3.0

require "inttegro"

client = Inttegro::Client.new(api_key: ENV.fetch("INTTEGRO_API_KEY"))
result = client.payment_methods.settings

Java

SDK versionv5.2.0

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();
  }
}

C#

SDK versionv6.2.0

using Inttegro;

using var inttegro = new InttegroClient(
    Environment.GetEnvironmentVariable("INTTEGRO_API_KEY")!
);
var result = await inttegro.PaymentMethods.SettingsAsync();

The response returns a settings object keyed by payment-method type.

Response

Object

SDK versionv8.2.0

SettingsResponse {
  settings: { … },
}

JSON

SDK versionv8.2.0

{
  "settings": {
    "mobile_money": { … },
    "bank_account": { … },
    "card": { … }
  }
}

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
type	Stable API identifier for the rail, such as mobile_money, bank_account, or card.
name	Human-readable label suitable for checkout and internal tools.
description	Short explanation of the rail. Use it as helper text, not as validation logic.
enabled	Whether your Inttegro account can use the rail for new payment-method or payment attempts.
confirms_use	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 enabled is true, you can present that payment rail and send requests that use it.

When enabled 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

confirms_use controls customer interaction, not whether a payment method is verified.

If confirms_use 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 confirms_use 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 enabled is true.
3. Render customer-facing choices using name and description.
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 enabled is true.
Why did a payment require OTP or another step?	Check confirms_use for the selected rail and inspect the payment's next action.
Can this merchant accept cards?	Look for a card entry with enabled: true.
Can this merchant accept mobile money?	Look for a mobile_money entry with enabled: 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 - Exact payment-method and settings contracts.
• Accept a payment - First payment flow with customer confirmation handling.
• Charge repeat customers - Using saved payment methods.
• Orders API reference - Payment execution through orders.