Skip to main content

​
Overview

For Mexican CFDI, payment_method describes payment timing. payment_form describes the payment instrument. Neither field is proof that money reached your account.

​
Payment Methods Table

​
PUE vs PPD: Key Differences

A CFDI’s fiscal status and a payment’s collection status belong to different records. An issued invoice can have status: "valid" before the customer pays. Do not require invoice status to be paid, partial_payment, or pending_payment: those are not the invoice completion states used by the documented recipes. Read the payment record and, for a PPD invoice, the linked complements and remaining balance. CFDI in five minutes explains the separate records.

​
What We See

The income-invoice request accepts exactly PUE and PPD for payment_method. Colombian issuers use those same API values with a different provider mapping; this page explains Mexico. See Colombia for its compatibility rules.

​
How to Use It

For the ordinary already-paid sale, send the actual payment instrument with PUE. For the ordinary unpaid sale, the tutorials use PPD with payment_form: "99". These are worked cases, not a complete account of every fiscal exception. Consult the SAT’s CFDI and payment-complement filling guides for the actual transaction.

​
Implementation Examples

​
PUE Invoice

Request fragment, placed at the top level of an income invoice or draft body:
This describes the tutorial’s already-paid bank transfer. Use the complete draft, preview, and issue recipe, including client and items.

​
PPD Invoice

Request fragment, placed at the top level of an income invoice or draft body:
Use Invoice now, get paid later for the complete flow. The income contract defines the full required body. Neither fragment is a complete request, and neither uses an invoice wrapper.

​
Business Scenarios

​
Payment Complement Requirements (PPD Only)

In the automatic PPD recipe, ppd_invoice_id is the original income invoice’s SAT UUID. Payment registration can finish before the complement stamps. Verify the linked complement UUID and parent invoice balance before marking the fiscal task complete. Do not also call Create payment complement for the same payment when automatic complement handling was requested. Choose one flow.

​
Common Implementation Patterns

Save the income UUID, each actual payment ID, and each resulting complement UUID. Keep one stable duplicate key per payment. After an ambiguous response, look up the existing payment and complement before retrying; do not generate a fresh key.

​
Important Considerations

A fiscal code does not collect money, change a customer’s payment terms, or establish a tax deduction. Select it from the transaction and applicable SAT guidance. PUE and PPD are timing codes, not payment-record or invoice-status enums.

​
Error Prevention

If the payment registration succeeded but a complement is absent, investigate the automation rather than recording the payment again. If the amount exceeds the remaining balance, reconcile the prior payments before changing the request. See Troubleshooting for observed errors and safe recovery.