First stable version

Validating a transfer

• From typed details. The operation is identified by date, amount, tracking key or numeric reference, sending bank, receiving bank and beneficiary account, and it is looked up at Banco de México (Banxico) with those details.
• From a receipt. The receipt image, or its https address, goes through optical character recognition (OCR), which extracts those same details. When the beneficiary account is not legible in the image, it is sent separately; if it is already registered as a beneficiary, it is recognised from the visible digits.
• The verdict. valid: the operation exists in the Comprobante Electrónico de Pago (CEP). not_found: it is absent. cep_unavailable: Banxico acknowledges the operation but has not published the receipt yet. error: an internal service failure.
• The official receipt. A validation with a valid verdict allows the CEP to be downloaded exactly as Banxico issues it, as XML or as PDF.
• Automatic retries. A verdict without a receipt is eligible for retry, because the CEP can be published later. The policy sets the number of attempts, the interval (from 300 to 86,400 seconds) and the verdicts that trigger it (not_found, cep_unavailable or error), across the whole account or on a single validation. A retry does not consume quota.

The panel

• Validations. The history, the detail of each operation with its associated image, and export to a file. Bulk upload accepts CSV, XLSX, XLS, TXT and JSON against a template, free text, loose images or a ZIP of images, and allows a single open job at a time.
• Beneficiaries. CLABE accounts, cards and DiMo phone numbers, with their structure checked on registration and with bulk import from a file.
• Finance. Monthly statement as PDF, XLSX, CSV or HTML; monthly, counterparty, per-bank and accounting reports; and the download of every receipt in a compressed archive.
• Notifications. Five channels — email, SMS, push, Telegram and in-app notices — configurable event by event, with quiet hours.
• Usage. The month's quota, history, breakdown and the heatmap of the account's activity.

The API

• A single envelope. Every response is made of data, errors and meta, so the code that reads it is written once and serves the remaining operations.
• One API key per account. It is revealed with an additional check and regenerated on demand: the previous key stops being valid at that moment and the account receives a security notice.
• Idempotency. The Idempotency-Key header keeps a repeated request from creating a second validation, within a 24-hour window. A 5xx response is not stored, so a server failure does not burn the key.
• Asynchronous mode. With ?async=1 the response is an immediate 202 carrying the validation identifier; the verdict is collected by polling the operation, and the ETag avoids downloading the same state twice.
• Signed webhooks. Eleven validation and billing events, up to ten per endpoint, with an HMAC-SHA256 signature on every delivery, a rotatable secret, a test delivery and a delivery log.

Plans and billing

• Public catalogue. Active plans, with their prices and their features, are read without a session.
• Free plan. It is claimed from the account, with no card.
• Card billing. Changing plan, cancelling, resuming and reading invoices happen in the billing portal, without support stepping in.
• Overage. On the plans that allow it, the account decides whether running out of quota stops the service or keeps billing it by usage.

Security and availability

• Image hardening. Before anything is persisted, the real format, the size and the dimensions are checked, and decompression bombs and files that can also be read as another format are rejected. Metadata — EXIF, XMP and ICC — is stripped, location included.
• Account protection. Two-factor authentication (2FA) and closing every open session from the profile.
• Service status. The status of verification at Banxico is read from the account, with the latency series of the last few hours.