Skip to main content

Overview

For Mexican CFDI, payment_form describes how the payment was made. For example, "03" is a bank transfer. It is separate from payment_method (PUE or PPD), which describes timing. Sending a code does not initiate or confirm a payment.

What We See

The income-invoice schema accepts the 22 string codes listed below. A code’s presence in the input enum does not mean it is appropriate for every transaction or document. The table preserves SAT labels; choose from the actual payment facts.

How to Use It

Send the code as a string so its leading zero is preserved. For the already-paid transfer example, use "03". For the ordinary unpaid invoice example, use "99" with PPD, then identify the actual instrument in the payment flow. See Payment methods.

Payment Forms Table

Implementation Examples

API Request Example

Top-level request fragment for the tutorial’s already-paid invoice:
This is not a complete invoice body. Follow the invoice recipe for required customer and line-item fields and the exact income contract. To record money already received, use the payment recipe.

Validation Logic

Check the enum on the endpoint being called. Validate membership separately from whether the instrument fits the actual transaction. A provider or wallet brand alone does not determine the SAT payment form; inspect the actual means of payment.

Common Use Cases

Do not map every PayPal or other wallet transaction to 05 merely from its brand. Use the SAT filling guidance for special instruments and combinations.

Important Notes

The Colombia guide explains the adapter’s different mapping: a transfer still uses the public API value "03", not the provider’s DIAN code "47". The labels in this catalog are Mexican SAT meanings.