canonical: https://jentic.com/apis/fattmerchant.com/fattmerchant # Fattmerchant Stax API The Stax API (formerly Fattmerchant) gives developers programmatic access to the payment-processing platform's core resources: transactions, customers, payment methods, and invoices. The 17-endpoint spec covers charging cards, voiding and refunding past transactions, storing customer payment methods, and issuing invoices for collection. Designed for merchants who want flat-rate processing with API-first integration into their own checkout or back-office. ## For AI agents Charge cards, void and refund transactions, manage customers and stored payment methods, and issue invoices on the Stax payment processing platform. ## Scope Does not handle accounting, payroll, or PCI scope reduction beyond tokenisation - use for Stax payment processing operations only. ## Capabilities - Charge a card and create transaction records via POST /transactions - Void a previous authorization via POST `/transactions/{transaction_id}/void` - Refund a captured transaction via POST `/transactions/{transaction_id}/refund` - Create and manage customer profiles for repeat billing via /customers and `/customers/{customer_id}` - Store and retrieve tokenised payment methods tied to a customer via /payment-methods - Issue invoices and retrieve invoice status via /invoices and `/invoices/{invoice_id}` ## Use cases ### Card-Present and Card-on-File Charging Merchants integrating Stax into their checkout call POST /transactions with a stored payment-method id or a one-time token to charge a customer. The API returns a transaction id used by downstream void and refund flows. Lets merchants implement card-on-file billing without exposing card data to their own systems. Example prompt: POST to /transactions with the customer id, payment_method_id, and amount, then store the returned transaction_id for later refund or void ### Refunds and Voids from Support Tools Customer support agents use back-office tools to void unsettled authorisations or refund settled charges through Stax. The agent calls `/transactions/{transaction_id}/void` for unsettled and `/transactions/{transaction_id}/refund` for settled transactions. Reduces support resolution time and removes the need for direct merchant portal access. Example prompt: Given a transaction_id, call POST `/transactions/{transaction_id}/void` if unsettled or POST `/transactions/{transaction_id}/refund` if settled ### Recurring Invoice Billing Service businesses issue invoices through Stax via POST /invoices and retrieve status updates via GET `/invoices/{invoice_id}.` The flow lets the merchant send a hosted payment link and reconcile collections through the API. Suits trades, agencies, and B2B services on flat-rate processing. Example prompt: POST /invoices with customer_id, line items, and due date, then poll GET `/invoices/{invoice_id}` for paid status ### AI Payment Operations Agent via Jentic Operations agents use Jentic to call Stax for support and reconciliation tasks like 'refund transaction X for customer Y'. Jentic resolves the intent to the right `/transactions/{transaction_id}/refund` call and supplies the bearer token from its vault. Agents never see the raw token and integration time drops from days to under an hour. Example prompt: Through Jentic, search 'refund a stax transaction', load `/transactions/{transaction_id}/refund`, and execute with the transaction id from the support ticket ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/transactions` | Create (charge) a new transaction | | GET | `/transactions/{transaction_id}` | Retrieve a transaction by id | | POST | `/transactions/{transaction_id}/void` | Void an unsettled authorization | | POST | `/transactions/{transaction_id}/refund` | Refund a settled transaction | | POST | `/customers` | Create a customer profile | | POST | `/payment-methods` | Store a payment method | | POST | `/invoices` | Issue an invoice | ## Key resources - **Transactions** — Charge, void, and refund card transactions - **Customers** — Create and retrieve customer profiles for repeat billing - **Payment Methods** — Store and remove tokenised payment methods linked to a customer - **Invoices** — Issue and track invoices with payment status ## Why Jentic - **Setup:** Wiring the Stax API by hand means handling its bearer auth and threading the transaction id through nested void and refund paths yourself. Through Jentic you install once, import Stax from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** Stax puts the transaction id in the URL path (`/transactions/{transaction_id}/void` and `/transactions/{transaction_id}/refund`), so a rule can pin your agent to one transaction. You choose the operations it may call, so destructive ones like void or refund are not included unless you add them, leaving reads and customer creation on their own. - **Credential handling:** Your Stax bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context, even when calling refund or void operations. - **Discovery method:** Agents search Jentic by intent such as 'charge a Stax customer' or 'refund a Stax transaction', and Jentic returns the matching operation with its input schema so the agent picks the right endpoint without browsing the docs. ## Related APIs - **Stripe** — Larger payment processing platform with broader feature set - **Square** — Payment processing alternative with strong card-present and POS support - **Braintree** — PayPal-owned payment processor for online merchants - **Stax** — Companion vendor entry under the current brand domain ## FAQ ### What authentication does the Stax API use? Stax uses HTTP Bearer token authentication - supply your Stax API key in the Authorization header as a bearer token. Through Jentic the bearer token is stored encrypted in the vault and injected at execution time, never entering the agent's prompt. ### Can I refund a transaction with the Stax API? Yes. POST to `/transactions/{transaction_id}/refund` for a settled transaction or `/transactions/{transaction_id}/void` for an unsettled authorization. The refund and void endpoints take the original transaction id from the response of POST /transactions. ### What are the rate limits for the Stax API? Stax does not publish explicit rate limits in the OpenAPI spec. Plan for moderate concurrency on transaction calls, batch reads on customers and invoices, and back off on 429 responses. ### How do I charge a stored card through Jentic? Install with pip install jentic, search 'charge a stax customer', load POST /transactions, and execute with the customer_id, payment_method_id, and amount. Get started with Jentic One, the self-hosted execution layer. ### Does the Stax API support recurring billing? The spec exposes /transactions, /customers, /payment-methods, and /invoices - recurring billing is implemented by storing a payment method on a customer and scheduling repeat POST /transactions calls. There is no built-in subscription endpoint in this API surface. ### Can I limit what my agent is allowed to do with the Stax API? Yes. Jentic One is self-hosted, so your own rules decide which Stax operations and credentials the agent may use, and you choose the exact set it can call. You can leave destructive operations like POST `/transactions/{transaction_id}/void` and POST `/transactions/{transaction_id}/refund` out of the allowed set while still permitting reads and POST /customers. Because Stax puts the transaction id in the URL path, a rule can pin the agent to a single transaction, and your bearer token is injected at execution time rather than exposed to the agent.