Skip to main content

Intake Overview

Intake is Triple's hosted dispute-capture UI. You embed it in your app, and it handles the conversation with the cardholder, collects the right evidence for the dispute type, and hands you back a ready-to-evaluate case.

Beta

The intake API shapes and events on this page are under active development. Endpoints and payload structures may change before general availability. Contact your Triple representative to enable intake on your account.

Why use intake​

  • You don't have to build dispute UX. Forms, chat flows, evidence uploaders, validations, copy that meets scheme expectations — we run all of it.
  • You don't have to classify. The flow adapts as the cardholder answers. By the time they finish, Triple knows whether the case is fraud, service-not-received, processing-duplicate, or cancelled. See Classification.
  • You don't have to host it. It's a Triple-owned URL you drop into an iframe. Nothing to deploy; changes we ship show up in your product automatically.

Two modes: form and chatbot​

Intake comes in two flavors. The one a cardholder sees depends on the session configuration you pick when you create it.

  • Smart form — a multi-step form that shows only the fields relevant to what the cardholder has said so far. Good default for most issuers.
  • Chatbot — a conversational flow asking questions one at a time. Better for lower-literacy users or mobile-first experiences.

Both collect the same data and produce the same output. You can switch between them per session, or let Triple pick based on the cardholder's context.

The session model​

Every intake is a session:

  1. Your backend calls POST /intake/sessions/ with whatever context you already have (transaction, cardholder ID, optional category hint).
  2. Triple returns a short-lived session URL and an ID.
  3. Your frontend embeds the URL in an <iframe> inside your dispute flow.
  4. The cardholder completes intake. Triple classifies the case and runs an evaluation under the hood.
  5. Your app is notified — via postMessage to the parent window and/or a webhook — with the intake_session_id and the evaluation_id.
  6. You fetch the evaluation result from GET /evaluations/{evaluation_id}/result exactly as in the direct path.

Sessions expire. Don't cache the URL — request a new session each time a cardholder starts the flow.

What Triple collects​

At minimum: a cardholder statement and any required scheme evidence for the classified category. Beyond that, the flow may also collect:

  • Attempts to contact the merchant
  • Receipts, tracking numbers, policy screenshots, and other attachments
  • Date the service was expected
  • Whether the card was in the cardholder's possession

You don't configure which fields appear — the flow decides based on what's been answered.

What Triple does not collect​

  • Full PAN (you pass the masked card snapshot at session creation)
  • Cardholder PII beyond what's needed for the dispute (email and name are optional)
  • Payment credentials or credentials for any merchant site

Next​

  • Integration — full step-by-step with the session creation call, iframe embed, and completion handling.
  • Events — the postMessage events emitted during and at the end of the flow.