Payment methods

Raims offers Pix and boleto. Checkout shows the options allowed for the charge, subject to platform availability and the charge, link, and account settings. Credit and debit cards are disabled and are not offered for payment.

Pix and boleto

For Pix, the payer uses the QR Code or Pix copy-and-paste code shown at checkout. For boleto, they use the document or payment line provided. Issuing payment details does not confirm that the charge has been paid. Check the charge status to track confirmation.

To adjust the account defaults, see Checkout and payment methods.

API codes

When creating a charge, use payment_method_types to set a custom list of accepted methods. Send the codes as numbers, without duplicates: [1] accepts Pix, [2] accepts boleto, and [1, 2] accepts both. A populated list overrides the account default for that charge only. It still respects the methods available on the platform, and a custom link configuration can reduce the options in that list.

Omitting payment_method_types or sending null keeps the charge using the configuration applied by checkout. When the link has no custom configuration, the current account default applies, including later changes to it. An empty list does not mean that the charge should use this configuration.

payment_method is a separate, optional field that defaults to 0 when omitted. Without a custom list, it has the following behavior:

Without payment_method_types, choosing payment_method: 1 or payment_method: 2 restricts the charge to that method. It does not enable an option disabled in the configuration used by checkout. If that method is disabled, no other method is offered as an alternative.

With a custom list in payment_method_types, omit payment_method or send 0. Do not combine the list with payment_method: 1 or payment_method: 2. The charge starts with an undefined method, even if the list allows only Pix or only boleto.

The list accepts only 1 and 2. Do not send 0, other codes, strings, booleans, or null items. None of these settings changes the account default or confirms payment. With payment_method: 1, available Pix details appear in payment_information.pix; with payment_method: 2, boleto details appear in payment_information.boleto. Pending issuance preserves the charge ID so you can track it through the individual retrieval endpoint. See Receive Pix details during creation and Receive boleto details during creation, including customer data and address completion by postal code (CEP).

Registered method and checkout selection

In API queries, payment_method reports the method currently registered for the charge. When Pix or boleto generation is recorded, an undefined charge changes from 0 to 1 or 2, according to the method used. payment_method_types reports the custom list configured during creation, or null when the charge uses the inherited configuration. This list does not change to reflect the selected method and does not represent the options available at that moment. checkout_payment_method reports the method recorded at checkout and returns null until that record exists.

For example, after Pix generation is recorded for a charge created with payment_method: 0, retrieval reports payment_method: 1 and checkout_payment_method: 1. Setting payment_method: 1 during creation requests direct Pix issuance. Selecting an option on the screen alone does not confirm generation or payment.

If the charge was created with payment_method_types: [1, 2], recording Pix generation makes retrieval report payment_method: 1, while preserving payment_method_types: [1, 2].

The payment_method filter in List charges considers the currently registered method. Clicking an option at checkout without recording generation does not make an undefined charge match the Pix or boleto filter.