Sandbox y producción
Un solo dominio, api.oden.tax, y una sola versión de la API. Lo que cambia entre
probar y facturar de verdad no es la dirección: es el sello con el que firmas.
El sello decide
En sandbox se firma con los CSD de prueba que el SAT publica, cuyo RFC es uno de los suyos:
EKU9003173C9 es el más usado. Cargar uno de ésos en un emisor lo deja timbrando
contra el ambiente de pruebas del PAC.
En producción se firma con el CSD real del contribuyente, el que descargó de su portal del SAT. Un CSD real contra el
ambiente de pruebas y un CSD de prueba contra producción devuelven los dos un rechazo: el PAC contesta
csd_not_from_sat en el segundo caso.
Los timbres
Un timbre se consume cuando el PAC certifica el comprobante. Un rechazo no lo gasta, y por eso vale la pena que lo que esté mal se rechace lo antes posible: antes de llegar al PAC validamos el XML contra el esquema del SAT, el uso del CFDI contra el régimen del receptor, y que la fecha del comprobante caiga dentro de las 72 horas.
Los del sandbox no se cobran. Es el lugar para probar los casos que dan miedo: una nota de crédito, una cancelación con motivo 01, una factura en dólares.
Todo es síncrono
Timbrar no pasa por una cola. POST /v1/mx/invoices sostiene la petición hasta que el
PAC contesta y devuelve el comprobante timbrado, o el motivo por el que no. Cuando la llamada regresa, la respuesta
es definitiva, salvo dos. pac_unavailable dice que el PAC no contestó y pudo haber
timbrado: reintenta con la misma llave y le preguntamos antes de timbrar otra vez. Y un
201 con status: "stamping" y sin
uuid es lo que contesta la misma llave mientras la primera llamada sigue esperando al
PAC: vuelve a preguntar en unos segundos.
Eso implica un timeout generoso de tu lado. Damos hasta 45 segundos al PAC; en la práctica contesta en dos o tres. Si tu cliente corta antes que nosotros, la factura pudo haberse timbrado sin que lo sepas, y para eso está la llave de idempotencia.