> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gigstack.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Payment Methods Catalog (Métodos de Pago)

> Integration guide for Payment Methods Catalog (Métodos de Pago)

## 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

| Code | SAT description | Ordinary flow in these tutorials |
| - | - | - |
| `PUE` | Pago en una sola exhibición | The example sale is already paid in full when the invoice is issued. |
| `PPD` | Pago en parcialidades o diferido | The example sale is unpaid or partly paid when issued; record subsequent payments and their complements. |

## 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](/concepts/invoicing) 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](/countries/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](https://www.sat.gob.mx/minisitio/Factura/emite_materialdeayudaparafactura.htm) for the actual transaction.

## Implementation Examples

### PUE Invoice

**Request fragment**, placed at the top level of an income invoice or draft body:

```json theme={null}
{"payment_method":"PUE","payment_form":"03"}
```

This describes the tutorial's already-paid bank transfer. Use the complete
[draft, preview, and issue recipe](/recipes/invoice), including client and items.

### PPD Invoice

**Request fragment**, placed at the top level of an income invoice or draft body:

```json theme={null}
{"payment_method":"PPD","payment_form":"99"}
```

Use [Invoice now, get paid later](/recipes/paid-later) for the complete flow.
The [income contract](/reference/createInvoicesIncome) defines the full required body.
Neither fragment is a complete request, and neither uses an `invoice` wrapper.

## Business Scenarios

| Situation | Next step |
| - | - |
| Sale paid in full before issuance | Follow the PUE invoice recipe with the actual payment form. |
| Unpaid sale, paid later in one transfer | Follow the PPD flow; a deferred single payment is still covered by that flow. |
| Customer makes several partial payments | Record each actual payment once, then verify its complement and remaining balance. |
| Customer has not paid but an invoice says `valid` | Treat it as fiscally issued; inspect payment records separately. |

## Payment Complement Requirements (PPD Only)

In the [automatic PPD recipe](/recipes/paid-later), `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](/reference/createInvoicesPayment) 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](/troubleshooting) for observed errors and safe recovery.

## Related Documentation

* [Payment forms](/guides/catalogs/payment_forms)
* [Paid-later recipe](/recipes/paid-later)
* [Record an existing payment](/recipes/payment)
* [Verification coverage](/verification)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.