Integrating LLMs with business systems: WhatsApp, payments and POS

What it is and what makes it hard

Connecting an LLM to business systems means making what the model decides end up in a channel or a real operation: a WhatsApp message, a charged subscription, a sale at a till. The hard part is not the model call but what surrounds it: channel windows and templates, duplicate or out-of-order events, rate limits and operations that cannot be repeated.

AgendaGo: the WhatsApp agent (in production)

• Everything sent to the customer goes through a single outbound path, which enforces the 24-hour window and WhatsApp templates. The model does not send messages on its own.
• Booking goes through three barriers: the slot comes from the availability engine in the same turn, the customer cannot have another booking that day and a database trigger blocks overbooking.
• A deterministic router answers about 44% of messages without calling the model.
• The app passed Meta’s review on 31 August 2026. AgendaGo also integrates MercadoPago.

Bonuxo: POS, e-commerce and billing (in production)

In Bonuxo I built the business-system integration and it is in production, but it does not go through a model: Bonuxo’s LLM is Nux, which is in construction and switched off in production. What follows is the base on which an agent could operate.

• A POS API with live and test keys (only the SHA-256 hash is stored), per-key and per-IP limits, an optional Idempotency-Key with 24-hour retention and exactly-once sales. OpenAPI 3.0.3 contract, version 1.3.0.
• Integrations verified in code with Fudo (POS), TiendaNube (e-commerce) and a MercadoPago POS adapter, with polling and reconciliation.
• Recurring billing with MercadoPago: webhook signature verified with HMAC-SHA256 in constant time, idempotent two-phase claim and handling of duplicate and out-of-order events.
• A load test against production, on 30 September 2026, with 3084 requests and 0 errors; it found that the per-key limit was not being applied, and I fixed it.

The underlying decision

In both projects the channel is controlled by deterministic code, not by the model: a single outbound path in WhatsApp, and idempotency and reconciliation in billing. It is more code per integration, in exchange for a model mistake not being able to duplicate a charge or break a channel’s window.