In payments support, the safe job for an AI agent is answering questions from your published documentation: fees, settlement timelines, how to raise a dispute, what a decline code means. The unsafe job is anything that moves money, changes an account, or asks a customer for card details in chat. Draw that line in your design, not in the prompt, and send disputes and fraud reports to people.

This post covers how to set that up, what LayBuild's redaction does and does not protect, and where PCI DSS fits. LayBuild has no PCI DSS certification or attestation, and nothing here is compliance advice for your specific setup.

Keep the agent read-only, by construction

A prompt that says "never issue refunds" is an instruction, not a control. The control is that the agent has no way to issue a refund.

In LayBuild, the agent's abilities come from two places: the knowledge base it retrieves from, and any API tools you attach. API tools are HTTP calls you configure (URL, method, auth, headers, parameters). They are not LLM function calling: after the agent writes its answer, each attached tool is called with its configured values, and the first successful result is shown alongside the reply. The model does not choose which tool to run or fill in arguments from the conversation.

That design is limiting, and for payments it is also the safe default. It means an attached tool runs on every answered turn of that agent, with the same parameters every time. So the rule is simple: never attach a tool that changes state. No refund endpoints, no card freeze, no limit changes, no payout triggers. A read-only call with fixed parameters, such as a public service status endpoint, is fine.

The same reasoning applies to anything customer-specific. Because tool calls do not carry the customer's identity or arguments, LayBuild cannot look up a particular customer's transaction today. For "where is my refund?" questions about a specific payment, the agent should explain your published timelines and hand off.

What LayBuild's redaction covers

LayBuild redacts some personal data from the agent's answers before they are sent. The output guardrail replaces text matching these patterns with [REDACTED], and it is on by default:

  • 16-digit card-like numbers, with optional spaces or hyphens between groups of four.
  • US Social Security numbers in the 123-45-6789 format.
  • Email addresses.
  • Phone numbers in common international formats.

Answers are also capped at 8,000 characters.

Here is where it sits in the reply pipeline:

text
customer message
      |
preflight guardrails (blocked terms, prompt-injection patterns, off-topic refusal)
      |
retrieve (Qdrant vector search + Postgres full-text + Q&A pairs, merged with RRF)
      |
generate --> grounding check (fixed no-answer reply if overlap with sources is too low)
      |
tool call (attached API tools, configured values)
      |
output guardrail (PII redaction on the answer text, length cap)
      |
handoff check --> reply to customer

What redaction does not cover

This is the part to read carefully before you rely on it.

It is output only. Whatever the customer types is stored as typed. If a customer pastes a full card number into the widget, that message is saved in the conversation history in Postgres. LayBuild encrypts stored LLM API keys, SMTP passwords, widget keys and uploaded files with AES-256-GCM, but conversations and messages are not encrypted at the application level. Your database encryption at rest, backups and access controls are what protect them.

The card pattern is narrow. It matches four groups of four digits. A 15-digit card number in the 4-6-5 grouping some networks use will not match, and neither will a number split by other characters. There are no dedicated patterns for CVVs, expiry dates, bank account numbers, IFSC codes, UPI IDs or national ID numbers such as Aadhaar. Some of those may be caught incidentally by the phone pattern; do not count on it.

It applies to the answer text only. Data returned by an attached API tool is shown alongside the answer, and that data does not pass through the redaction step. Another reason not to attach tools that return customer data.

It can redact things you want shown. Your own support email address or helpline number in an answer matches the email and phone patterns and will be replaced. If customers need that contact detail, put it somewhere the widget shows outside the answer, or test your key answers and adjust the wording.

Card data in chat, and PCI DSS

The PCI Security Standards Council's position on card numbers in chat is direct. Its FAQ 1085 (checked September 2026) says PCI DSS Requirement 4.2.2 prohibits sending unprotected primary account numbers via end-user messaging technologies, which covers chat, and that strong cryptography is required when cardholder data is involved.

For an AI support channel, the practical reading is: design so that card numbers do not enter the chat at all. If cardholder data is stored in or passes through your support system, that system and the infrastructure around it may come into scope for your PCI DSS assessment. Ask your assessor rather than assuming either way.

The steps that follow from that:

  • Never ask for card details in chat. Check your knowledge base for any article that says "send us your card number" and rewrite it. The agent answers from your content, so it will repeat what your content says.
  • Tell customers not to share card numbers. Put that in the widget's greeting and in the answers about payment problems.
  • Identify transactions by something that is not cardholder data, such as your own transaction or order reference, and have a human look it up in your internal tools.
  • Treat any card number that does arrive as an incident for your process to handle (deletion, logging), not something the AI deals with.

Send disputes and fraud reports to people

Chargebacks, unauthorised transaction reports, account takeovers and complaints have deadlines, evidence requirements and legal consequences. The agent's job is to explain the process and get the customer to a human quickly.

Be precise about how handoff works in LayBuild, because it does not detect topics or sentiment. Handoff happens in two cases. The customer asks for a person in words the handoff pattern recognises (phrases like "talk to a human", "real person", "escalate", "customer support"), and your organisation has human handoff enabled, which is off by default. Or the conversation passes 25 AI turns. Asking about a dispute does not, by itself, trigger a handoff.

So build the path into your content and settings:

  • Turn on human handoff for the organisation.
  • Write your dispute, fraud and unauthorised-payment articles so they end with a clear instruction such as "Type 'talk to a human' to reach our disputes team now", plus your other contact routes.
  • Subscribe to the CONVERSATION_HANDOFF webhook and create a case in your own system when it fires, so a handoff outside staffed hours is not lost. Deliveries are logged but not retried, so make your endpoint reliable.
  • Staff the dashboard. On handoff, agents get a real-time alert and can take over the conversation. There is no AI-written summary, so the agent reads the transcript.

Where the model runs

Every message the agent answers is sent, with retrieved context, to the LLM provider you use. For a payments company, that provider is part of your data flow and belongs in your vendor review. LayBuild supports several hosted providers and any OpenAI-compatible endpoint, which includes models you host yourself, and the platform can be self-hosted with Docker Compose from the open-source repository.

Next steps