RAG Over Your Payment Documentation and Transaction History
Two RAG pipelines for Paystack: 1) Documentation RAG — embed Paystack API docs, your integration notes, error code reference, webhook event catalogue. Query when someone asks "what does this error mean" or "how should I handle X". 2) Transaction history RAG — store transaction records in a database queryable by the LLM via tools. Query when someone asks "find transactions matching this pattern" or "what happened to this customer". Keep transaction data in your own infrastructure — never send raw PII-containing transaction records to third-party embedding services.
Documentation RAG: Paystack Error Codes and API Docs
// Build a documentation RAG index for Paystack error codes and API reference
// Using a simple embedding + cosine similarity approach
// Step 1: Create documentation chunks
var docChunks = [
{
id: 'error-insufficient-funds',
text: 'Error: "Insufficient Funds". The customer's bank declined the transaction because the account balance was too low. This is a card_decline error from the bank. Customer action: ask the customer to use a different card or top up the account. Do not retry the same card immediately.',
tags: ['error', 'card', 'decline'],
},
{
id: 'error-do-not-honor',
text: 'Error: "Do Not Honor" (gateway_response: "Do Not Honour"). The issuing bank declined without giving a specific reason. Common causes: fraud suspicion, card flagged, transaction type restriction. Customer action: ask the customer to contact their bank or use a different card.',
tags: ['error', 'card', 'decline'],
},
{
id: 'webhook-charge-success',
text: 'Webhook event: charge.success. Fired when a transaction is successfully completed. Always verify the payment status by calling GET /transaction/verify/:reference before fulfilling the order. The webhook payload contains data.reference, data.amount (in kobo), data.customer.email, and data.status which should be "success".',
tags: ['webhook', 'charge'],
},
// Add more chunks for each error code, each endpoint, each webhook event...
];
// Step 2: Embed chunks (using any embedding model)
async function buildDocIndex(chunks) {
var indexed = [];
for (var chunk of chunks) {
var embedding = await embedText(chunk.text); // your embedding function
indexed.push({ ...chunk, embedding });
}
return indexed;
}
// Step 3: Retrieve relevant chunks for a query
async function retrieveRelevantDocs(query, docIndex, topK = 3) {
var queryEmbedding = await embedText(query);
return docIndex
.map(doc => ({ ...doc, score: cosineSimilarity(queryEmbedding, doc.embedding) }))
.sort((a, b) => b.score - a.score)
.slice(0, topK);
}
// Step 4: Augment prompt with retrieved docs
async function answerPaymentQuestion(question, docIndex) {
var relevantDocs = await retrieveRelevantDocs(question, docIndex);
var context = relevantDocs.map(d => d.text).join('
');
var response = await anthropic.messages.create({
model: 'claude-opus-4-6',
max_tokens: 512,
messages: [{
role: 'user',
content: 'Payment documentation:
' + context + '
Question: ' + question,
}],
system: 'Answer the payment question using only the documentation provided. If the answer is not in the documentation, say so.',
});
return response.content[0].text;
}
Transaction History: Tool-Based Retrieval
For transaction history, use tool calling rather than vector embeddings. Transaction records contain PII and financial data — query them from your own database via tools, not by embedding them in an external vector store:
// Tool calling for transaction retrieval (safer than embedding PII data)
var transactionTools = [
{
name: 'search_transactions',
description: 'Search transaction history by various filters.',
input_schema: {
type: 'object',
properties: {
reference: { type: 'string' },
customer_email: { type: 'string' },
date_from: { type: 'string' },
date_to: { type: 'string' },
status: { type: 'string' },
amount_min: { type: 'number' },
amount_max: { type: 'number' },
},
},
},
];
// Executed against your own DB — not an external service
async function executeSearchTransactions(input) {
return db.transactions.search(input); // your own DB, you control the data
}
This way, the LLM gets transaction data it needs without the raw records ever leaving your infrastructure.
Learn More
See building an AI agent that queries Paystack transactions for the full tool calling pattern.
Key Takeaways
- ✓Documentation RAG answers "what does this mean" questions grounded in your actual integration docs.
- ✓Transaction RAG answers "what happened with payment X" questions from your own transaction database.
- ✓Keep transaction records with customer PII in your own infrastructure — do not embed them in third-party vector stores.
- ✓Chunk documentation at the natural boundary: one chunk per API endpoint, one per error code, one per webhook event.
- ✓Combine RAG with tool calling: docs RAG for explanation, Paystack API tools for live data retrieval.
Frequently Asked Questions
- Can I embed raw Paystack transaction records in a vector store like Pinecone?
- Technically yes, but this is a bad idea for production. Transaction records contain customer PII (email, name, authorization details) and financial information. Sending these to a third-party embedding service creates a data residency and privacy risk. Instead, use tool calling to query your own database — the LLM gets the information it needs without the raw data leaving your infrastructure.
- What is the best chunk size for Paystack documentation in RAG?
- Chunk at natural content boundaries, not arbitrary token counts. Good chunking: one chunk per error code (the code, its meaning, customer action, developer action). One chunk per webhook event (event name, payload structure, when it fires, what to do with it). One chunk per API endpoint (endpoint, method, key parameters, response structure). This makes retrieval precise — a query about "insufficient funds" retrieves the single relevant chunk, not a big block of mixed error documentation.
- How do I keep my documentation RAG index up to date when Paystack updates their API?
- Treat your RAG index like code — keep the source documents in a repository and re-build the index when they change. Create a PAYSTACK_DOCS.md or PAYMENT_ERRORS.md in your project with your annotated notes on each error code and endpoint. Update it when you encounter new behavior. Re-embed and re-index on any update. Your annotated notes are often more useful than raw Paystack documentation because they include your specific integration context.
Ready to build real-world apps?
Join the McTaba Labs full-stack marathon (4 months full-time · 6 months part-time). Learn M-Pesa, USSD, and WhatsApp engineering while shipping 8 production apps.
Apply to the McTaba Marathon