Pinch Payments Hackathon 2026 · LyboTech Group (Adelaide) · solo build

Remi — the AI payments teammate.
Built on Pinch in one weekend.

One build, three surfaces: the first Pinch MCP server, ready-to-deploy agents on LyboAI, and a live platform integration in CoachPlus. This page is the build summary — written for developers and for the business side, and shared for feedback.

Every write previews first, executes on approval Verified against the Pinch test environment1
23 MCP tools 3 surfaces: MCP · agents · platform every write needs confirm:true BYO keys — no aggregation Pinch test env1

The story

Businesses lose money in the payment gaps

Billing that takes weeks to set up. Direct debits that bounce quietly and never get chased. Money questions that wait for whoever does the books. Remi is an AI payments and billing teammate that closes those gaps, on a four-part operating model.

Design

Set up billing

One-touch billing setup plus customer import — describe how you charge, get a validated blueprint and a go-live pack.

Do

Move the money

Payment links, subscriptions and bill splits created on request — each one previewed before it exists.

Ask

Answer live

Live money answers — what came in, what failed, what is scheduled, who owes what — from real Pinch data.

Fix

Recover failures

Failed-payment diagnosis and recovery — cause identified, retry planned, customer note drafted.

The rule underneath all four: every money-moving action previews first and executes only on human approval. That gate is enforced in the tool layer, not in the prompt.

What got built

One weekend, three surfaces

The same payments core, delivered as a developer tool, a deployable agent family, and a working platform integration.

pinch-mcp

The first Pinch MCP server: 23 tools over the Pinch API (payments, subscriptions, splits, refunds, and QR payment links), usable from Claude, Cursor or any agent host. Hosted multi-tenant — every caller brings their own Pinch keys. Writes are confirm-guarded, refunds are capped, and the public endpoint refuses the live environment outright.1

23 toolsconfirm-guarded writesrefund capslive-env refusal

Agents on LyboAI

Ready-to-deploy Remi (back office) and Remi Front Desk (customer-facing, restricted to a safe tool subset). One click from the Agent Family, connected per organisation with the business's own Pinch keys.

Remi — back officeFront Desk — customer-facingper-org keys

CoachPlus integration

Pinch is the live platform's payments provider. In-product: hosted checkout and QR links, term / weekly / fortnightly subscriptions with deposits (direct debit), refunds, cancellations, bill splits and discount codes on customer payments, webhook-driven GST invoices, dishonour diagnosis, a payments simulator, and a floating Remi assistant. The coach action routes call the MCP engine today; a native REST path is a polish item.

hosted checkout + QRterm/weekly subscriptionsrefunds · splits · discountswebhook GST invoicessimulator

View the live platform ↗

Three actors, BYO keys

Every business owns its merchant relationship

The model has three distinct actors, and none of them shares credentials with another. A platform ships the agents; each business connects with its own Pinch keys; customers pay only on hosted Pinch pages.

1

Platform owner

e.g. CoachPlus

Integrates Pinch as its payments provider and ships the Remi agents to its businesses.

  • Runs the product, checkout flows and webhooks
  • Deploys agents — never holds merchant keys
2

Each business

coach · studio · school

Registers directly with Pinch, owns its own keys, and gets a scoped back-office Remi.

  • Direct Pinch merchant account — its own money, its own keys
  • Approves every money-moving action Remi proposes
3

End customers

members · parents · clients

Meet the Front Desk agent on the business's own channels and pay only via hosted Pinch pages.

  • Restricted tool subset — no card data ever touches the agent
  • Payment happens on Pinch's hosted checkout, nowhere else
No aggregation. The platform never pools or proxies funds — every business owns its merchant relationship with Pinch directly. Each platform that adopts this model adds its businesses to Pinch's merchant base as real, individual merchants.

Domain depth

Payments knowledge, built in

The tools encode how Australian direct-debit billing actually behaves — for developers, that means less glue code; for the business side, it means answers in plain English.

Dishonour taxonomy

Every failure code maps to a plain-English cause, who owns the problem (customer, bank or business), whether a retry is safe, and a drafted customer note.

1-touch onboarding

A billing blueprint, payer import and per-payer setup links come together as a go-live pack — from a description of how the business charges to ready-to-send links.

Stall detection

Subscriptions that have quietly stopped charging are surfaced before they become months of missed revenue.

Split-bill exposure

Shared bills show who has paid, who still owes, and how much of the total is being carried by whoever fronted it — with chase-up links ready.

Settlement visibility

What has settled, what is on its way to the bank, and when — so "the money left the customer" and "the money arrived" stop being confused.

Cashflow digests

A periodic summary of collected, dishonoured and scheduled amounts, with the payments at risk called out — the numbers an owner actually checks.

Security by design

Guardrails in the tool layer, not the prompt

A payments MCP server is a target. The controls below are enforced in code, reviewed against published MCP security guidance, and documented with a standards mapping and production roadmap in SECURITY.md.

Reviewed against the OWASP GenAI Secure MCP Server guide, the SlowMist MCP checklist and Palo Alto Networks' MCP analysis — with the standards mapping and production roadmap published in SECURITY.md.

Architecture & data flow

Card and bank details never reach the Studio, the model, or this MCP server

Payment details are captured by Pinch CaptureJS or a Pinch-hosted page in the payer's own browser, so they never touch the application server — and therefore never enter the chat transcript, the model context, an MCP request, or telemetry. The build has no card or bank-account field anywhere: the 23 tool schemas in pinch-mcp contain no cardNumber, cvv, bsb or accountNumber parameter, and payer payment sources are only ever established through a Pinch-hosted link (pendingSetup).

A · Where payment data goes, and where it never goes

In PCI DSS scope — Pinch only Model context Control-plane check, implemented Bounded and unlogged, implemented Pipeline — Polish Week Prohibited — never crosses
flowchart TB classDef pci fill:#FFF1E9,stroke:#F26522,stroke-width:2px,color:#8A3A10 classDef agent fill:#EEF2FF,stroke:#4F46E5,stroke-width:1.5px,color:#312E81 classDef ctrl fill:#F3EFFF,stroke:#7C5CFC,stroke-width:1.5px,color:#3F2E7E classDef dlp fill:#ECFDF5,stroke:#1E9E5A,stroke-width:1.5px,color:#12603A classDef next fill:#F3EFFF,stroke:#7C5CFC,stroke-width:1.5px,stroke-dasharray:5 4,color:#3F2E7E classDef never fill:#FEF2F2,stroke:#DC2626,stroke-width:1.5px,stroke-dasharray:5 4,color:#991B1B classDef plain fill:#FFFFFF,stroke:#D8DAE5,color:#1A1A2E subgraph CAP["Payer's browser — where payment details are captured"] direction TB P1["Payer opens a Pinch-hosted
setup or payment link"]:::plain P2["Pinch CaptureJS or Pinch-hosted page
the card and bank fields belong to Pinch"]:::pci P1 --> P2 end subgraph ST["LyboAI Studio — agent plane"] direction TB O["Operator, in natural language"]:::plain D1["PIPELINE · Inbound redaction
remove · tokenise · mask"]:::next M["Model context"]:::agent D2["PIPELINE · Outbound redaction"]:::next N1["Never present in this plane
PAN · BSB · account number · CVV · PIN
Pinch secret key · OAuth token"]:::never O --> D1 --> M --> D2 end subgraph MC["pinch-mcp — constrained financial control plane"] direction TB Z["Zod schema validation,
every argument"]:::ctrl G["confirm:true guard, enforced in the
tool handler and not in prompt text"]:::ctrl T["23 narrow tools · no generic call_api
no card or bank field in any schema"]:::ctrl N2["Never accepted as a tool argument
PAN · BSB · account number · CVV · PIN"]:::never Z --> G --> T end PINCH["Pinch — the only plane that holds payment credentials
tokenisation and vault: PAN · BSB · account number · CVV
api.getpinch.com.au"]:::pci R1["Bounded output, 200 kB cap
no parameters or results logged"]:::dlp R2["PIPELINE · Response redaction scan"]:::next UI["Token reference · source type · last four · status
returned to the model, then to the operator"]:::plain P2 ==>|"credentials travel browser to Pinch, direct"| PINCH D2 -->|"intent plus tokenised references only"| Z T -->|"OAuth2 client credentials, per-request secret
token cached in memory, 55 minutes"| PINCH PINCH --> R1 --> R2 --> UI

Scroll the diagram sideways to read it in full.

Mermaid source — data-handling boundaries
flowchart TB
  classDef pci fill:#FFF1E9,stroke:#F26522,stroke-width:2px,color:#8A3A10
  classDef agent fill:#EEF2FF,stroke:#4F46E5,stroke-width:1.5px,color:#312E81
  classDef ctrl fill:#F3EFFF,stroke:#7C5CFC,stroke-width:1.5px,color:#3F2E7E
  classDef dlp fill:#ECFDF5,stroke:#1E9E5A,stroke-width:1.5px,color:#12603A
  classDef next fill:#F3EFFF,stroke:#7C5CFC,stroke-width:1.5px,stroke-dasharray:5 4,color:#3F2E7E
  classDef never fill:#FEF2F2,stroke:#DC2626,stroke-width:1.5px,stroke-dasharray:5 4,color:#991B1B
  classDef plain fill:#FFFFFF,stroke:#D8DAE5,color:#1A1A2E

  subgraph CAP["Payer's browser — where payment details are captured"]
    direction TB
    P1["Payer opens a Pinch-hosted<br/>setup or payment link"]:::plain
    P2["Pinch CaptureJS or Pinch-hosted page<br/>the card and bank fields belong to Pinch"]:::pci
    P1 --> P2
  end

  subgraph ST["LyboAI Studio — agent plane"]
    direction TB
    O["Operator, in natural language"]:::plain
    D1["PIPELINE · Inbound redaction<br/>remove · tokenise · mask"]:::next
    M["Model context"]:::agent
    D2["PIPELINE · Outbound redaction"]:::next
    N1["Never present in this plane<br/>PAN · BSB · account number · CVV · PIN<br/>Pinch secret key · OAuth token"]:::never
    O --> D1 --> M --> D2
  end

  subgraph MC["pinch-mcp — constrained financial control plane"]
    direction TB
    Z["Zod schema validation,<br/>every argument"]:::ctrl
    G["confirm:true guard, enforced in the<br/>tool handler and not in prompt text"]:::ctrl
    T["23 narrow tools · no generic call_api<br/>no card or bank field in any schema"]:::ctrl
    N2["Never accepted as a tool argument<br/>PAN · BSB · account number · CVV · PIN"]:::never
    Z --> G --> T
  end

  PINCH["Pinch — the only plane that holds payment credentials<br/>tokenisation and vault: PAN · BSB · account number · CVV<br/>api.getpinch.com.au"]:::pci
  R1["Bounded output, 200 kB cap<br/>no parameters or results logged"]:::dlp
  R2["PIPELINE · Response redaction scan"]:::next
  UI["Token reference · source type · last four · status<br/>returned to the model, then to the operator"]:::plain

  P2 ==>|"credentials travel browser to Pinch, direct"| PINCH
  D2 -->|"intent plus tokenised references only"| Z
  T -->|"OAuth2 client credentials, per-request secret<br/>token cached in memory, 55 minutes"| PINCH
  PINCH --> R1 --> R2 --> UI

B · Drafting is separated from execution

Implemented in the current release Pipeline — Polish Week Blocked, with an audit event
flowchart TB classDef now fill:#ECFDF5,stroke:#1E9E5A,stroke-width:1.5px,color:#12603A classDef next fill:#F3EFFF,stroke:#7C5CFC,stroke-width:1.5px,stroke-dasharray:5 4,color:#3F2E7E classDef stop fill:#FEF2F2,stroke:#DC2626,stroke-width:1.5px,color:#991B1B classDef plain fill:#FFFFFF,stroke:#D8DAE5,color:#1A1A2E I["Operator states the commercial intent
'$59 a week for 10 weeks, $100 deposit'"]:::plain DR["Draft — the tool composes the call and returns
a structured preview. Nothing is created."]:::now VA["Validate — zod schema · currency · merchant binding ·
refund cap · fee preview · dishonour rules"]:::now DEC{"Human approves
the preview?"} NO["No write occurs. Preview returned,
audit event written."]:::stop AP["Approve — the caller repeats the call
with confirm:true"]:::now AO["PIPELINE · Polish Week
Signed short-lived approval object bound to:
payer token · merchant · amount + currency · purpose ·
source token · approving user · expiry · draft hash"]:::next CH{"PIPELINE
Amount, recipient or draft
hash changed since approval?"} RJ["Rejected — approval invalidated,
audit event written"]:::stop EX["Execute — one Pinch write,
sent with an idempotency nonce"]:::now OK["Redacted structured response, plus one audit line
carrying a hashed tenant tag and no parameters"]:::now I --> DR --> VA --> DEC DEC -->|"no"| NO DEC -->|"yes"| AP AP --> AO --> CH CH -->|"yes"| RJ CH -->|"no"| EX EX --> OK

Scroll the diagram sideways to read it in full.

Mermaid source — draft / validate / approve / execute
flowchart TB
  classDef now fill:#ECFDF5,stroke:#1E9E5A,stroke-width:1.5px,color:#12603A
  classDef next fill:#F3EFFF,stroke:#7C5CFC,stroke-width:1.5px,stroke-dasharray:5 4,color:#3F2E7E
  classDef stop fill:#FEF2F2,stroke:#DC2626,stroke-width:1.5px,color:#991B1B
  classDef plain fill:#FFFFFF,stroke:#D8DAE5,color:#1A1A2E

  I["Operator states the commercial intent<br/>'$59 a week for 10 weeks, $100 deposit'"]:::plain
  DR["Draft — the tool composes the call and returns<br/>a structured preview. Nothing is created."]:::now
  VA["Validate — zod schema · currency · merchant binding ·<br/>refund cap · fee preview · dishonour rules"]:::now
  DEC{"Human approves<br/>the preview?"}
  NO["No write occurs. Preview returned,<br/>audit event written."]:::stop
  AP["Approve — the caller repeats the call<br/>with confirm:true"]:::now
  AO["PIPELINE · Polish Week<br/>Signed short-lived approval object bound to:<br/>payer token · merchant · amount + currency · purpose ·<br/>source token · approving user · expiry · draft hash"]:::next
  CH{"PIPELINE<br/>Amount, recipient or draft<br/>hash changed since approval?"}
  RJ["Rejected — approval invalidated,<br/>audit event written"]:::stop
  EX["Execute — one Pinch write,<br/>sent with an idempotency nonce"]:::now
  OK["Redacted structured response, plus one audit line<br/>carrying a hashed tenant tag and no parameters"]:::now

  I --> DR --> VA --> DEC
  DEC -->|"no"| NO
  DEC -->|"yes"| AP
  AP --> AO --> CH
  CH -->|"yes"| RJ
  CH -->|"no"| EX
  EX --> OK
Positioning. This architecture is designed to minimise PCI DSS scope — it is not a claim of PCI DSS compliance. No part of this build has been formally assessed, and the hackathon build runs against the Pinch test environment with synthetic customers only.

PCI scope & privacy

One rule per data class, applied at every boundary

The table below is the rule set the build is written against. It is a design contract, not a certification: the columns say what each plane is permitted to see, and the prohibitions are absolute rather than consent-dependent.

Data-handling boundaries

Data classAgent / model contextMCP serverStorage
Sensitive authentication data
CVV/CVC, PIN and PIN blocks, full track data
NeverNever Never after authorisation
Raw payment credentials
full PAN, bank account number
NeverAvoided entirely Pinch tokenisation boundary only
Security credentials
Pinch secret key, OAuth tokens, API keys
NeverIn-memory retrieval only, request-scoped Secrets manager / KMS
Tokenised payment references PermittedPermitted Encrypted
Display-safe payment data
brand, source type, last four
Permitted when necessaryPermitted Limited retention
Personal information
name, email, address, phone, IP
Redacted or pseudonymisedOnly when operationally necessary Purpose-limited
Transaction information Permitted with a pseudonymous customer IDPermitted Financial retention policy
Unstructured content
prompts, uploaded invoices, OCR, generated code
Pipeline — redaction scan before use Pipeline — redaction scan in both directions No raw prompt retention
What the standard says. PCI DSS prohibits storing CVV/CVC, PIN and PIN blocks and related sensitive authentication data after authorisation, even when encrypted. A customer cannot consent around that prohibition, so it is enforced as an absence of fields rather than as a policy.

Redaction path — pipeline

What exists today. The absence of card and bank fields in every tool schema, hosted-only capture of payment sources, request-scoped credentials, hashed tenant tags in audit lines with no parameters or results logged, and a 200 kB cap on tool output. There is no content-classification layer in this release: the boundary is currently enforced by what the schemas cannot accept, not by scanning.

What is planned. Two redaction passes on the way out and one on the way back, with three treatments: remove (CVV, full PAN, passwords, API secrets), tokenise (payer identity, payment source, bank-account reference) and mask (Visa •••• 4242, payer_7F21, $99 AUD). Model context will carry session-scoped aliases such as CUSTOMER_01, with the alias-to-identity map held in a separate encrypted vault the model cannot reach. Detection is to cover structured tool arguments, free text, uploaded documents, OCR output, generated code, model outputs, error messages, traces, audit logs and support exports. Where classification fails, or a probable card number appears where one should not exist, the request fails closed.

Australian privacy obligations

ObligationWhat appliesHackathon build todayPipeline
APP 1 — open and transparent management A clearly expressed, up-to-date privacy policy covering how personal information is handled Data-handling rules published here and in SECURITY.md Product privacy policy and collection notice per deployed workspace
APP 3 — collection of solicited personal information Collect only what is reasonably necessary for a function or activity Synthetic customers only; tools request name, email and amount — no card or bank fields Field-level necessity review per tool before live operation
APP 11 — security of personal information Reasonable steps to protect information, and to destroy or de-identify it when no longer needed TLS in transit, no credentials at rest on the server, hashed tenant tags in logs, bounded outputs Retention schedules with automated destruction and de-identification jobs
Personal information is broader than names Transaction history, IP addresses, device identifiers, location and combinations of otherwise harmless data may identify someone Pseudonymous customer IDs in model context; audit lines carry a hashed tenant tag, not a merchant ID Re-identification risk assessment across the combined telemetry set
Consent and purpose limitation Specific consent for a stated purpose, rather than a broad “AI use” consent Not applicable — no real personal information is processed in the sandbox build Per-purpose consent capture, and model-provider and cross-border disclosure review
Access and correction Individuals may request access to, and correction of, their personal information Payer records are readable and correctable through Pinch Documented access and correction workflow with response timeframes
Notifiable Data Breaches Assess suspected eligible breaches and notify the OAIC and affected individuals Per-call audit logging provides the evidence trail for assessment Written NDB response plan, with SIEM alerting on failed-validation and high-frequency patterns
Automated-decision transparency
commences 10 December 2026
Privacy policies must disclose automated decisions that use personal information where those decisions significantly affect an individual's rights or interests Remi makes no such decision: it drafts, previews and explains — a human approves every write Disclosure statement, plus a standing prohibition on creditworthiness, hardship and KYC-override decisions by the agent

What the agent may and may not do

The agent mayThe agent may not do autonomously
Interpret commercial requirements; recommend a Pinch pattern; generate a billing blueprint; explain fees and schedules; create drafts and previews; simulate failures; identify reconciliation differences Charge a customer; increase an amount; change the receiving merchant; refund a settled payment; create or modify payout details; retry indefinitely; make creditworthiness or financial-hardship decisions; override compliance or KYC status
Financial execution stays deterministic, bounded and reviewable. The MCP server is a constrained financial control plane, not a generic proxy: there is deliberately no pinch.call_api(method, endpoint, body) tool, because a generic passthrough would let prompt injection turn the agent into an unrestricted API client.

Verified against the real sandbox

Everything shown ran against the Pinch test environment

No mocked screenshots. Each scenario below was executed against the live Pinch test environment, and the captures on the main page are the actual outputs.1

The playground on the main page replays these captures offline, or speaks MCP Streamable HTTP to a pinch-mcp endpoint you run.

Feedback

This page exists to be argued with

The build is being shared for review. Two questions, two audiences — replies to either go to the same inbox.

For developers

What would you want from a Pinch MCP or agent toolkit? Missing tools, different guard semantics, other transports, a different hosting shape — specifics are the useful kind of feedback.

23 tools todaywhat should be next?
Give feedback →

For the Pinch team

Does the three-actor model fit how you see platforms growing the merchant base? Each platform adoption brings its businesses to Pinch as direct merchants — is that the shape you want, and what would make it easier?

no aggregationdirect merchant relationships
Give feedback →
1 The public pinch-mcp endpoint is sandbox-only: it targets the Pinch test environment and refuses live unless a self-hosted operator explicitly enables it.
2 Remi and pinch-mcp are an independent community build on the Pinch API by LyboTech Group — not a Pinch product, and not affiliated with Pinch Payments.