---
name: thai-slip-verification
description: Verify Thai bank transfer slips by calling the CheckSlip MCP tools — confirm the amount, receiver, and transfer date, and detect duplicate or reused slips. Use whenever a customer sends a payment slip (an image, a QR payload, or a transaction reference number) to confirm a bank transfer before fulfilling an order.
---

# Thai Bank Slip Verification

Verify Thai bank transfer slips with the **CheckSlip** remote MCP server. Use
this skill to confirm that a customer actually paid — checking the amount,
receiver, and transfer date — and to make sure the same slip is not reused for
two orders.

## Prerequisites

This skill calls tools from the CheckSlip MCP server, so that server must be
connected first:

- Endpoint: https://thaibankslip.com/mcp
- Setup guide: https://thaibankslip.com/docs
- Auth: OAuth 2.1 — sign in once with your store name + API key (`csk_…`).

Once connected, two tools are available:

- `check_slip` — verify a slip and (optionally) mark it as used.
- `slip_checker_status` — report provider/config health (no secrets). Useful as
  a connection smoke test before verifying real slips.

If the tools are not available, tell the user to connect the CheckSlip MCP
server (see https://thaibankslip.com/docs) and stop — do not guess whether a slip is valid.

## When to use this skill

Use it when a customer provides proof of a bank transfer and you need to confirm
it before shipping goods, releasing a service, or marking an order paid — for
example "ลูกค้าส่งสลิปมา" / "here is my payment slip" / "I transferred the
money, here's the receipt".

## How to verify a slip

1. **Collect the slip.** Get exactly one of:
   - `slip_image_base64` — the original full-resolution slip image (PNG/JPEG),
     base64-encoded. The QR is decoded server-side.
   - `qr_payload` — the raw QR string read from the slip.
   - `transaction_ref` — the slip's transaction reference number.
2. **Add what you expect (recommended).** If you know the order details, pass
   `expected_amount`, and optionally `expected_receiver_name`,
   `expected_receiver_account_last4`, and `expected_transfer_date`
   (`YYYY-MM-DD`). The tool then confirms the slip matches the order, not just
   that it is a real slip. Pass `order_id` to record the result against your
   order.
3. **Call `check_slip`** with those fields.
4. **Prevent reuse.** Only once you accept the slip and fulfill the order, call
   `check_slip` again (or the same call) with `mark_as_used: true` so any later
   attempt to reuse that slip returns `duplicate`. Do not mark a slip used until
   you are committing to the order.

## Interpreting the result

The result `status` is one of:

- `verified` — the slip is genuine and (if you passed expectations) matches.
  Safe to fulfill the order.
- `failed` — the slip could not be verified or did not match (wrong amount,
  unknown/too-old slip, etc.). Do **not** fulfill. Tell the customer the slip
  could not be verified and ask for a correct one.
- `duplicate` — this slip was already used for a previous order. Do **not**
  fulfill; the customer is reusing an old slip.
- `provider_error` — the verification service is temporarily unreachable. This
  is a system problem, not the customer's fault. Ask them to try again shortly;
  do not tell them their slip is invalid.
- `config_error` — the server is misconfigured. Surface it to the operator; the
  customer cannot fix this.

Always read the human-readable `message` and the `checks` object (e.g.
`amount_match`, `duplicate`) to explain the outcome clearly.

## Examples

Verify by transaction reference and confirm the amount:

```
check_slip({ transaction_ref: "2024XXXXXXXX", expected_amount: 250, order_id: "order-1042" })
```

Verify a slip image and, on success, mark it used so it cannot be reused:

```
check_slip({ slip_image_base64: "<base64>", expected_amount: 250, mark_as_used: true })
```

Smoke-test the connection:

```
slip_checker_status({})
```

## Guardrails

- Never decide a slip is valid on your own — always rely on `check_slip`. The
  image alone is not proof; only the embedded QR / reference is verified.
- A `provider_error` or `config_error` is never the customer's fault — do not
  tell them their payment is invalid in that case.
- Do not set `mark_as_used: true` until you are actually fulfilling the order.