#1139 — Processor matching

Repo: Twill-AI/facade State: open | Status: open Assignee: meliascosta

Created: 2026-03-19 · Updated: 2026-03-19

Description

Summary

Implement processor matching / suitability for merchants whose onboarding application has enough data: evaluate which payment processors (PayEngine, Luqra, EMS, etc.) are suitable to file the application, persist results, recompute when merchant context changes, and notify the partner UI (e.g. via existing activity → WebSocket path).

This work is a concrete slice of the NBA / AI-assisted onboarding epic (#977); backend design notes align with signal ingestion (#983), persistence (#979), and WS/action delivery (#981).

Decision engine: suitability and processor ranking/matching MUST be produced using an LLM integrated from the twill_llm_engine repo (not hard-coded rules-only long term). Facade orchestrates: build a structured merchant snapshot + processor constraints/prompts, call the llm_engine, validate/persist structured output, then emit realtime updates.

Scope (high level)

  1. Trigger — When application data crosses an explicit completeness gate (and again when fingerprinted inputs change): schedule background evaluation (e.g. after partner/master merchant PUT, after doc-driven application updates).
  2. LLM — Add/adapt a twill_llm_engine capability (prompt + response schema) that takes normalized merchant context and returns per-processor suitability (eligible / not, rationale, optional ordering or confidence).
  3. Persistence — Store results + input_fingerprint + ti

Notes

Add implementation notes, blockers, and context here

Add wikilinks to related people, meetings, or other tickets