Conversect CALL-E e-commerce integration

Conversact: AI phone calls as the storefront. Customer texts Telegram, authorizes a call, CALL-E places it to collect orders, Jalolink handles pricing and payment, receipt sent back.

Comment

Jalolink Conversact: AI Phone Calls as the Storefront

Conversact turns a simple message into a complete conversational checkout.

A customer starts in Telegram, explicitly authorizes one phone call, and CALL-E calls them to understand what they want to buy. They speak naturally instead of navigating a storefront. Conversact turns that conversation into structured purchase intent, Jalolink independently validates the real products, prices and stock, Paystack handles payment, and the customer's receipt is delivered back through Telegram.

Telegram
   ↓
Explicit consent
   ↓
CALL-E conversation
   ↓
Structured purchase intent
   ↓
Jalolink validation
   ↓
Authoritative checkout
   ↓
Paystack
   ↓
Receipt back in Telegram

The phone call becomes the shopping interface — without giving the AI authority over money, inventory or payment state.

The Problem

Most online commerce is designed around screens: browse a catalog, build a cart, fill a checkout form and pay.

But sometimes customers already know what they want and would rather simply say it.

AI phone agents make that possible, but introducing generative AI directly into a commerce transaction creates a new problem: a misunderstood product, hallucinated price or ambiguous confirmation must never become a real order simply because an AI said so.

Conversact explores a safer model:

Let AI understand the customer. Let deterministic systems control the transaction.

The Solution

Conversact separates conversational intelligence from commercial authority.

1. Explicit, one-use customer consent

The workflow begins only when the customer intentionally starts Conversact through Telegram, shares their phone number using Telegram's native contact control, and explicitly approves a single phone call.

No background campaign or unsolicited calling occurs.

Each authorization is purpose-bound and one-use.

2. CALL-E handles the conversation

CALL-E becomes the conversational interface.

It can ask what the customer wants, clarify ambiguous requests, collect quantities and understand delivery intent.

Its output is treated as evidence of purchase intent, not as an instruction that is automatically trusted.

3. Jalolink establishes commercial truth

After the call, the Jalolink backend independently reloads:

  • the referenced products;
  • current prices;
  • current stock;
  • delivery rules;
  • applicable commerce state.

CALL-E cannot authoritatively decide the price or final order total.

Even if a spoken or structured result contains the wrong amount, that amount never becomes the amount charged to the customer.

The governing rule is:

CALL-E expresses intent. Jalolink establishes commercial truth.

4. Paystack establishes payment truth

Once Jalolink has produced an authoritative order, Conversact initializes a Paystack test-mode checkout.

A redirect, client callback or Telegram message is never considered proof of payment.

Only verified payment reconciliation changes the order into a paid state.

5. Jalolink issues the receipt

After verified payment, Jalolink renders its own PNG receipt and Conversact sends it directly back to the customer through Telegram.

The complete customer journey becomes:

Message → consent → phone call → checkout → payment → receipt.

What I Built During the Hackathon

Conversact was implemented incrementally through phases T0–T9, with each phase having explicit acceptance gates before progressing.

The completed system includes:

  • Telegram bot onboarding and authenticated webhook ingestion.
  • Durable Telegram update deduplication.
  • Sender-bound phone capture using Telegram's native contact-sharing flow.
  • Explicit one-use CALL-E authorization.
  • Replay-safe callback handling.
  • A real CALL-E call validated end-to-end using CALL-E's official US test hotline.
  • Structured CALL-E result processing.
  • Safe rejection of ambiguous and non-ordering evidence.
  • Authoritative Jalolink product, stock and pricing validation.
  • Server-generated commerce quotes independent of CALL-E-provided prices.
  • Paystack test-mode payment initialization.
  • Paystack webhook reconciliation as payment authority.
  • PNG Jalolink receipt generation.
  • Automatic receipt delivery through Telegram.
  • Deterministic workflow identifiers.
  • Stable CALL-E idempotency keys.
  • Idempotent processing designed to preserve at most one logical call/order effect under duplicate provider or network delivery.
  • 99+ automated unit and integration tests.
  • Auditability across the major workflow transitions.

Hard Safety Boundaries

Conversact deliberately limits what each system is allowed to decide.

Component Responsible for Not trusted to decide
Telegram Customer interaction and consent Payment status or order truth
CALL-E Conversational understanding Authoritative price, stock, total or payment state
Jalolink Products, stock, pricing, delivery and orders Payment settlement
Paystack Payment verification Product or fulfillment decisions

This means a single AI misunderstanding does not automatically become a bad commercial transaction.

A CALL-E result must cross deterministic application boundaries before any consequential state change occurs.

Handling Uncertainty

Conversact does not assume every completed phone call produced a valid order.

Results can fail closed when the evidence is:

  • ambiguous;
  • incomplete;
  • unrelated to ordering;
  • inconsistent with available products;
  • insufficient to prove customer intent.

A phone call completing successfully and a customer placing a valid order are treated as different events.

That distinction became one of the core architectural principles of the project.

Architecture

Conversact was deliberately built as an orchestrator rather than tightly coupling Telegram, CALL-E and Jalolink.

                ConversationChannel
                       │
                       ▼
              ConversactOrchestrator
                       │
              ┌────────┴────────┐
              │                 │
              ▼                 ▼
          CALL-E Port       Commerce Port
                                │
                                ▼
                             Jalolink
                                │
                                ▼
                          Payment Port
                                │
                                ▼
                            Paystack

The current hackathon channel is Telegram.

But Telegram is an adapter, not part of the core business logic.

A future implementation could add:

  • WhatsApp;
  • RCS;
  • another chat platform;
  • another commerce backend;
  • another supported payment provider;

without rewriting the central Conversact orchestration rules.

Why Telegram?

The original product direction explored WhatsApp because conversational commerce should begin where customers already communicate.

For the hackathon implementation, Telegram provided a faster and more controllable integration surface while preserving the same architecture.

This became useful architecturally: Conversact now treats messaging platforms as interchangeable ConversationChannel adapters rather than building the commerce workflow around a single messaging provider.

Real CALL-E Integration

Conversact does not simulate CALL-E as its only execution path.

The system performed a real outbound CALL-E call end-to-end using the official US testing hotline supplied by CALL-E support.

The application maintains deterministic workflow identity and stable provider idempotency so that retries are reconciled against the same logical operation rather than automatically creating another call.

CALL-E is therefore not merely mentioned in the architecture — it is the real conversational execution layer.

A Real Provider Constraint I Had to Engineer Around

My original target customers use Nigerian +234 numbers.

Nigeria was listed as a supported recipient region, but during live testing CALL-E returned:

422 call_not_ready
English calling for Nigeria is not currently supported

I initially investigated this as a possible payload, KYC or account configuration problem.

CALL-E support later explained that regional risk controls had recently been tightened and instructed me to validate the hackathon integration using their official US test hotline.

Instead of hiding that limitation, Conversact now treats provider routing availability as an external capability rather than assuming telephony routes are always operational.

That means the commerce architecture remains destination-independent even when a particular telephone route is temporarily unavailable.

What Building Conversact Taught Me About CALL-E

The hackathon exposed two particularly useful developer-experience lessons.

API contract/documentation drift

During development I encountered a mismatch between an earlier published recipient example using a singular:

recipient: {...}

and the request structure accepted by the live integration:

recipients[].phones[]

This caused unnecessary debugging at the first-call integration boundary.

I have documented the request/response evidence for formal feedback. Where the public documentation has since been corrected, I am treating this as a dated beta API/documentation drift issue, not claiming the current documentation necessarily remains unchanged.

Runtime routing availability

The larger issue was the difference between a region being documented as supported and that route actually being available under current platform risk controls.

I recommend CALL-E eventually expose a machine-readable capability/preflight check so an application can determine:

region
+
language
+
current routing policy
        ↓
callable / restricted / unavailable

before promising a customer that a call is about to occur.

Why This Matters Beyond Jalolink

Conversact is not intended to be a “Nigerian grocery voice bot.”

Jalolink is simply the first real commerce implementation.

The underlying problem is universal:

How can a natural human conversation safely cross into a transactional software system?

The same architecture can apply anywhere a catalog-backed business wants customers to begin a transaction conversationally while keeping consequential decisions deterministic.

Examples include:

  • local retail;
  • grocery and convenience commerce;
  • restaurants;
  • repeat-order businesses;
  • social commerce;
  • small merchants;
  • other catalog-backed commerce systems.

Conversact's contribution is the boundary between:

human conversation
        ↓
AI interpretation
        ↓
structured evidence
        ↓
deterministic application policy
        ↓
transaction

rather than a particular storefront.

Why It Fits CALL-E

Many phone agents stop after the conversation.

Conversact uses the phone call as one stage inside a larger stateful workflow.

Before the call:

  • customer identity;
  • explicit authorization;
  • workflow identity;
  • replay protection.

During the call:

  • natural conversational ordering;
  • clarification;
  • structured evidence collection.

After the call:

  • evidence validation;
  • catalog reconciliation;
  • authoritative pricing;
  • payment initialization;
  • payment reconciliation;
  • receipt delivery.

The call is therefore not the end product.

It is the human interface to a larger software transaction.

Why It Matters for the Hackathon

Real-World Impact

Conversact demonstrates a complete conversational-commerce workflow attached to an existing commerce backend rather than an isolated voice-agent prototype.

Quality of Idea

The phone conversation becomes a new checkout interface while the AI is deliberately prevented from becoming the authority over commercial state.

Technical Implementation

The project includes:

  • real CALL-E execution;
  • deterministic orchestration;
  • idempotency;
  • replay protection;
  • explicit consent;
  • structured evidence handling;
  • authoritative commerce validation;
  • verified payment reconciliation;
  • automated receipt delivery;
  • 99+ automated tests.

Product Experience

From the customer's perspective, the system reduces to:

Start a chat. Approve one call. Say what you want. Pay. Receive your receipt.

The Core Principle

Conversact is built around one sentence:

The AI can understand the transaction. It cannot declare the transaction true.

CALL-E understands the customer's intent.

Jalolink decides what can actually be sold and for how much.

Paystack decides whether money actually moved.

Only then does the customer receive a receipt.

That separation is what turns Conversact from a phone-call demo into a transactional AI system with hard safety boundaries.

Built With

Share this project:

Updates

Submission history