¿Cómo acepto pagos con Pix en mi sitio web?

Estático o dinámico: la decisión que define todo lo demás

El Banco Central de Brasil define ambos en su Manual de Padrões para Iniciação do Pix (la versión vigente es la 2.10.0). En un código estático, todo lo necesario para iniciar el pago está dentro de la propia imagen: un dato obligatorio, una clave Pix registrada en el directorio DICT, y cuatro opcionales: un identificador de la transacción, un campo de texto libre, el importe y un campo que solo usa Pix Saque. El manual dice que un código estático puede crearlo directamente el software del propio receptor, y afirma en mayúsculas que crearlo NO forma parte de la API Pix. Tu sitio puede generarlo; no hace falta que intervenga ningún banco.

Un código dinámico, en cambio, contiene una URL en el servidor de tu proveedor de pagos, que la app del comprador consulta en el momento de escanear para obtener el importe y los datos de la transacción. Como solo tu proveedor puede servir esa URL, un código dinámico siempre viene de un proveedor —la API Pix de tu banco o una empresa de pagos— y ese mismo proveedor es el que puede avisar a tu sitio cuando entra el dinero. La regla práctica: si el pago tiene que desbloquear algo automáticamente (una descarga, una cuenta, una reserva), necesitas la vía dinámica y algo en el servidor que reciba el aviso, la misma línea que traza ¿mi sitio web necesita un backend?. Si una persona puede revisar el banco antes de enviar, basta con un código estático con el importe.

Lo que encontramos en los sitios que alojamos

AgentCeres —el AI Growth Officer de agentceres.com— aloja páginas que los clientes crean con su agente, y la mayoría de esos clientes están en Brasil. Cuando contamos, el 23 de septiembre de 2026, 54 de 173 páginas de clientes publicadas mencionaban Pix y 78 mostraban precios en reales. El problema era cómo cobraban:

1. Nueve páginas incluían un código Pix que la IA había escrito a mano. Un BR Code termina con una suma de verificación calculada sobre todos los caracteres anteriores, y el manual señala que incluso el orden de los campos la cambia. Un código con un solo carácter mal no se lee: al menos un cliente nos dijo que la app de su banco no podía escanear el suyo.
2. Veintidós páginas mostraban la clave Pix como texto. Funciona, pero el comprador escribe el importe, así que los pagos erróneos o parciales son fáciles. Un propietario había pedido usar su CPF, lo que pone un documento fiscal personal en una página pública; una clave aleatoria cumple la misma función sin eso.
3. El pago lo "demostraba" el comprador. Los formularios de pedido le pedían al comprador que marcara una casilla diciendo que había pagado y que subiera una captura de pantalla, lo que solo demuestra que alguien sabe hacer una captura.

Así que incorporamos la vía estática a nuestro alojamiento, y las decisiones son la parte que sirve a cualquiera. El código se genera a partir de la clave del propio dueño, así que el banco del comprador paga directamente al banco del dueño y nunca tenemos el dinero. El importe se calcula en nuestro servidor a partir de los precios de la página publicada, nunca de un total que envía el navegador, porque el visitante puede modificar cualquier cosa de la página. Si el importe no se puede calcular, la generación falla en lugar de caer en un código sin importe. Y la confirmación sigue siendo manual: el dueño revisa su banco y marca el pedido como pagado, y la página del comprador indica que espera al vendedor hasta entonces.

Cómo hacer bien un código estático

Hay un detalle que juega a favor del comprador. El manual dice que el nombre que ve quien paga antes de confirmar es siempre el registrado en el DICT para esa clave, y el nombre del receptor escrito en el código se ignora. Así el comprador puede comprobar quién recibe realmente el dinero, diga lo que diga la página; conviene señalarlo junto al botón. Si prefieres cerrar la venta en una conversación en lugar de en la página, un botón de WhatsApp que envía el pedido es la alternativa habitual, y los dos funcionan bien juntos.