Saves and manages customer-owned payment methods.
A payment method always belongs to its attached customer. Tokenization may start a verification flow; inspect the returned verification state before attempting a charge. The API returns masked or provider-safe details and never returns raw reusable credentials.
Summary
Functions
Mark an inactive payment method as active so it can be reused in new payment flows.
Archive a payment method. Archived payment methods become inactive immediately and reject further updates until they are unarchived.
Mark an active payment method as inactive so it cannot be reused in new payment flows until reactivated.
Retrieve details for a specific payment method by ID. Returns the full payment method object including verification status, creation timestamp, masked account details, and owner details when captured.
Retrieve a paginated list of payment methods for the authenticated application. If customer_id is supplied, the page is scoped to payment methods that belong to that customer. The supplied customer must belong to your authenticated application.
Retrieve payment method acceptance settings for your application. Returns configuration for all supported payment types (mobile money, bank accounts, cards, Motito) including whether each type is enabled and requires customer confirmation. Use this to: - Show only enabled payment methods in checkout - Require explicit consent when confirms_use is true - Display acceptance preferences to merchants
Save a mobile-money payment method for an existing customer without charging it. Direct tokenization currently supports mobile_money; send the wallet details and owner identity described by the request schema. The returned payment method can be reused only while it is active, unarchived, and non-ephemeral. This operation supports idempotency.
Unarchive an archived payment method so it can be updated again. Unarchiving does not automatically reactivate the payment method.
Update mutable payment method metadata for the authenticated application. Supported updates: - custom_data merges into existing metadata - owner applies patch semantics and updates only the provided owner fields - active toggles whether the payment method can be reused - archived archives or unarchives the payment method Custom Data Merge Semantics: - New keys are added to existing custom_data - Existing keys are updated with new values - JSON null explicitly deletes the key - Keys not present in the update are preserved When adding a new owner address to a payment method that does not already have one, owner.address.country is required. Archived payment methods reject all updates except a pure unarchive request. Unarchiving leaves the payment method inactive until you activate it again.
Functions
@spec activate( Inttegro.Client.t(), Inttegro.PaymentMethods.ActivateRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Mark an inactive payment method as active so it can be reused in new payment flows.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.ActivateRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.ActivateRequest.new!(request_attributes)
case Inttegro.PaymentMethods.activate(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec archive( Inttegro.Client.t(), Inttegro.PaymentMethods.ArchiveRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Archive a payment method. Archived payment methods become inactive immediately and reject further updates until they are unarchived.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.ArchiveRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.ArchiveRequest.new!(request_attributes)
case Inttegro.PaymentMethods.archive(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec deactivate( Inttegro.Client.t(), Inttegro.PaymentMethods.DisactivateRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Mark an active payment method as inactive so it cannot be reused in new payment flows until reactivated.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.DisactivateRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.DisactivateRequest.new!(request_attributes)
case Inttegro.PaymentMethods.deactivate(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec lookup( Inttegro.Client.t(), Inttegro.PaymentMethods.LookupRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Retrieve details for a specific payment method by ID. Returns the full payment method object including verification status, creation timestamp, masked account details, and owner details when captured.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.LookupRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.LookupRequest.new!(request_attributes)
case Inttegro.PaymentMethods.lookup(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec page(Inttegro.Client.t(), Inttegro.PaymentMethods.PageRequest.t(), keyword()) :: {:ok, Inttegro.PaymentMethods.Page.t()} | {:error, Exception.t()}
Retrieve a paginated list of payment methods for the authenticated application. If customer_id is supplied, the page is scoped to payment methods that belong to that customer. The supplied customer must belong to your authenticated application.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.PageRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.Page.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.PageRequest.new!(request_attributes)
case Inttegro.PaymentMethods.page(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec settings(Inttegro.Client.t(), keyword()) :: {:ok, Inttegro.PaymentMethods.Settings.t()} | {:error, Exception.t()}
Retrieve payment method acceptance settings for your application. Returns configuration for all supported payment types (mobile money, bank accounts, cards, Motito) including whether each type is enabled and requires customer confirmation. Use this to: - Show only enabled payment methods in checkout - Require explicit consent when confirms_use is true - Display acceptance preferences to merchants
Parameters
client— an authenticatedInttegro.Client.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.Settings.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
Inttegro.PaymentMethods.settings(client)@spec tokenize( Inttegro.Client.t(), Inttegro.PaymentMethods.TokenizeMobileMoneyRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Save a mobile-money payment method for an existing customer without charging it. Direct tokenization currently supports mobile_money; send the wallet details and owner identity described by the request schema. The returned payment method can be reused only while it is active, unarchived, and non-ephemeral. This operation supports idempotency.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.TokenizeMobileMoneyRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.TokenizeMobileMoneyRequest.new!(request_attributes)
case Inttegro.PaymentMethods.tokenize(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec unarchive( Inttegro.Client.t(), Inttegro.PaymentMethods.UnarchiveRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Unarchive an archived payment method so it can be updated again. Unarchiving does not automatically reactivate the payment method.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.UnarchiveRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.UnarchiveRequest.new!(request_attributes)
case Inttegro.PaymentMethods.unarchive(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end@spec update( Inttegro.Client.t(), Inttegro.PaymentMethods.UpdateRequest.t(), keyword() ) :: {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} | {:error, Exception.t()}
Update mutable payment method metadata for the authenticated application. Supported updates: - custom_data merges into existing metadata - owner applies patch semantics and updates only the provided owner fields - active toggles whether the payment method can be reused - archived archives or unarchives the payment method Custom Data Merge Semantics: - New keys are added to existing custom_data - Existing keys are updated with new values - JSON null explicitly deletes the key - Keys not present in the update are preserved When adding a new owner address to a payment method that does not already have one, owner.address.country is required. Archived payment methods reject all updates except a pure unarchive request. Unarchiving leaves the payment method inactive until you activate it again.
Parameters
client— an authenticatedInttegro.Client.request— aInttegro.PaymentMethods.UpdateRequestcontaining the operation input.options— request options such as:idempotency_keyand additional:headers.
Returns
Returns {:ok, Inttegro.PaymentMethods.PaymentMethod.t()} when Inttegro accepts and decodes the operation. Returns
{:error, exception} for API, transport, or decoding failures. A successful API response can
still describe an asynchronous resource that has not reached its terminal state.
Example
request = Inttegro.PaymentMethods.UpdateRequest.new!(request_attributes)
case Inttegro.PaymentMethods.update(client, request) do
{:ok, result} -> result
{:error, error} -> {:error, error}
end