Library
Transaction enrichment library for Rails
Use TxnKit as a transaction enrichment API from Rails. This page shows the safe request shape, a short code snippet, and the boundary for keeping sensitive data out of the integration.
Target intent
Rails applications that need cleaner merchant names and warnings for transaction UI.
TxnKit should run in controller, job, or service code that keeps secrets server-side.
Raw descriptor
PAYPAL *ACME-SUPPLYShort Rails API snippet
response = Faraday.post("https://api.txnkit.dev/v1/enrich") do |request|
request.headers["Authorization"] = "Bearer #{ENV.fetch("TXNKIT_API_KEY")}"
request.headers["Content-Type"] = "application/json"
request.body = { raw_description: params[:raw_description], country: "CA" }.to_json
end
render json: JSON.parse(response.body), status: response.statusKeep API keys out of browser bundles. For frontend stacks, call a backend route or serverless function that owns the TxnKit request.
API-shaped output
{
"input": {
"descriptor": "PAYPAL *ACME-SUPPLY",
"country": "CA"
},
"output": {
"merchant_name": "Acme Supply",
"category": "Business supplies",
"confidence": "medium",
"signals": [
"processor_pattern",
"merchant_alias",
"category_hint"
],
"warnings": [
"review_low_confidence_matches_before_showing_logo"
],
"logos": []
}
}Low-confidence results should keep fallback labels and warnings visible instead of forcing a guessed logo or website.
When to use
- You are building in Rails and need one-descriptor merchant cleanup through an HTTP API.
- Your app can keep the TxnKit API key on the server side or inside a trusted serverless function.
- You need merchant display names, categories, confidence, signals, warnings, and logo-ready metadata.
When not to use
- TxnKit should run in controller, job, or service code that keeps secrets server-side.
- Do not use TxnKit to process card numbers, account numbers, full statements, bank credentials, emails, phone numbers, addresses, customer names, or customer PII.
- Do not use TxnKit when the product requirement is guaranteed merchant identity, every-merchant resolution, or contracted uptime terms.
Proof surfaces
The public contract is POST /v1/enrich, backed by the OpenAPI file, benchmark examples, privacy rules, and deterministic request-path tests.