Stax API

Name: Stax API API
Brand: Stax API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentPaymentsPayment Processingbearer17 EndpointsREST

For Agents

Charge cards, void and refund transactions, manage customers and stored payment methods, and issue invoices on the Stax payment processing platform.

Connect the Stax API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Stax API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Stax API API.

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}

GET STARTED

Start building with Stax API API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for Stax API, keeping it validated and agent-ready.

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.

Use Cases

Patterns agents use Stax API API for, with concrete tasks.

★ 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.

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.

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.

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.

Through Jentic, search 'refund a stax transaction', load /transactions/{transaction_id}/refund, and execute with the transaction id from the support ticket

Key Endpoints

17 endpoints — the stax api (formerly fattmerchant) gives developers programmatic access to the payment-processing platform's core resources: transactions, customers, payment methods, and invoices.

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

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

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Stax bearer tokens are stored encrypted in the Jentic vault. Agents receive scoped execution access — the raw token never enters prompt context, even when calling refund or void operations.

Intent-based discovery

Agents search '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.

Time to first call

Direct integration: 2-3 days for bearer auth, transaction state handling, and refund logic. Through Jentic: under an hour — search, load, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

Stripe

Larger payment processing platform with broader feature set

Choose Stripe for international, multi-currency, or advanced subscription needs; choose Stax for flat-rate US merchants

Alternative

Square

Payment processing alternative with strong card-present and POS support

Choose Square when in-person POS is the primary channel; Stax leans more toward online and recurring card-on-file

Alternative

Braintree

PayPal-owned payment processor for online merchants

Choose Braintree when PayPal acceptance is needed alongside cards; Stax focuses on flat-rate card processing

Complementary

Stax

Companion vendor entry under the current brand domain

Use the stax.com entry when references appear under the rebranded domain; functionality overlaps with this fattmerchant.com spec

FAQs

Specific to using Stax API API through Jentic.

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. Sign up at https://app.jentic.com/sign-up.

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.