Payments

AnythingPay works in both directions. An application can send a member to a checkout page to collect a payment, or move Points from the application owner's balance to a member. Both flows settle in one transaction and leave a receipt.

Applications are created in the Applications tool. Payment requests are available to confidential applications only, because the status check uses the client secret.

Requirements

• The application is active and has a client secret.
• The redirect_uri exactly matches one registered for the application.
• The member is signed in and has two-factor authentication enabled.
• The member has enough Points, and the payment is inside the per-payment and daily limits.

Create a checkout session

The application's server creates the request, authenticates with its client secret, and receives a checkout link. This proves the request came from the application, so another site cannot build a checkout under its name.

curl -X POST https://anything-advertising.com/pay/sessions \
  -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET \
  -d redirect_uri=https://example.com/paid \
  -d amount=4.99 \
  -d currency=USD \
  -d description="Premium role" \
  -d items='[{"name":"Premium role","quantity":1}]' \
  -d state=RANDOM_STATE \
  -d reference=order-1042 \
  -d payer=482

The response contains a short-lived checkout link and the reference:

{
  "ok": true,
  "reference": "order-1042",
  "checkout_url": "https://anything-advertising.com/pay/checkout?request=...",
  "expires_in": 900
}

Redirect the member's browser to checkout_url. The link expires with the configured checkout lifetime and can be opened by the intended member only when payer is set. The Points amount is fixed when the session is created.

Direct checkout link

For a simple payment link you can also build the checkout URL directly. The application name and registered return address still make the request identifiable, but a server-created session is the stronger option. Use an unguessable reference (or omit it and let the server generate one) when the link is shared; a reference is settled only once.

Redirect the member to the checkout endpoint with these query parameters:

Parameter	Value
client_id	The application's client ID.
redirect_uri	One of the application's registered redirect URIs.
amount	A positive amount. 5.00 for USD, or a whole number for Points.
currency	USD (default) or POINTS.
description	A short line describing the purchase. Optional.
items	A URL-encoded JSON array of items. Optional.
state	An unguessable value returned unchanged on the callback. Optional.
reference	Your own reference, 1 to 64 letters, digits, dots, colons, underscores or dashes. Optional; a random one is generated when omitted.
payer	The member's sub from AnythingAuth. Optional; when set, the checkout refuses to charge a different signed-in account.

https://anything-advertising.com/pay/checkout?client_id=YOUR_CLIENT_ID&redirect_uri=https%3A%2F%2Fexample.com%2Fpaid&amount=4.99&currency=USD&description=Premium%20role&state=RANDOM_STATE&reference=order-1042

Items are names with an optional quantity. Keep the total amount in amount; item amounts are not used.

[
  {"name": "Premium role", "quantity": 1},
  {"name": "Server slot", "quantity": 2}
]

The checkout page shows the application, the amount in Points and USD, the items, the member's balance, and whether the payment fits the daily allowance. The member enters an authenticator code or a backup code and chooses Pay or Cancel.

Callback

After the member decides, the browser returns to your registered redirect_uri with:

Parameter	Value
payment	The payment reference.
status	paid or denied.
state	The value you sent, unchanged.

The browser callback is a hint, not proof. Confirm the result on your server before delivering anything, and compare the returned reference, status and amount with the order you created.

Confirm a payment

Call the status endpoint from your server with the client ID and secret over HTTP Basic. Send the reference as a form field:

curl -X POST https://anything-advertising.com/pay/status \
  -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET \
  -d reference=order-1042

A settled payment returns:

{
  "ok": true,
  "payment": {
    "reference": "order-1042",
    "kind": "charge",
    "status": "paid",
    "amount_points": 499,
    "amount_usd": 4.99,
    "requested_amount": 4.99,
    "requested_currency": "USD",
    "description": "Premium role",
    "items": [{"name": "Premium role", "quantity": 1}],
    "created_at": "2026-10-27T18:40:12Z",
    "paid_at": "2026-10-27T18:40:19Z",
    "payer": {"id": 482, "username": "example"},
    "payee": {"id": 91, "username": "app-owner"},
    "app": {"client_id": "YOUR_CLIENT_ID", "name": "Example App"}
  }
}

Unknown references return 404. A reference that belongs to another application is treated as unknown.

Send a payment to a member

An application can pay a member from the Points balance of the account that owns it. This is the reverse of a checkout: the member does not approve anything, and the application authenticates the request with its client secret.

curl -X POST https://anything-advertising.com/pay/send \
  -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET \
  -d recipient=482 \
  -d amount=10.00 \
  -d currency=USD \
  -d description="Balance payout" \
  -d reference=payout-1042

Parameter	Value
recipient	The member's sub from AnythingAuth. Required.
amount	A positive amount. 5.00 for USD, or a whole number for Points.
currency	USD (default) or POINTS.
description	A short line describing the payment. Optional.
items	A URL-encoded JSON array of items. Optional.
reference	Your own reference for idempotency. A random one is generated when omitted.

The response is the same payment object returned by the status endpoint, with kind set to payout and status set to pending. It also includes a claim_url for the recipient. Reusing a reference returns the original payment without creating another.

The recipient receives a notification and opens a payment page showing the application, amount, description, items, sender, reference and date. They can accept or decline there. No Points move until they accept, so poll the status endpoint before delivering anything. A payout ends as paid or denied.

The application owner's balance must cover the amount when the recipient accepts, and the daily outgoing limit applies at that point. The recipient sees the payment in their Payment history.

Security

• Two-factor authentication is required. A checkout cannot be approved with only the account session.
• The member sees the application, amount, items and description before approving. The checkout data is bound to the request; it cannot be changed by editing the page.
• Checkout payments settle immediately. Payouts stay pending until the recipient accepts. Do not deliver goods or services until the status endpoint returns paid.
• Payouts debit the application owner's balance only when the recipient accepts. Keep the client secret server-side; anyone with it can create payments from that balance within the configured limits.
• Reuse the same reference when retrying a checkout link. A settled reference never moves money twice.
• The amount is settled in Points. USD requests are converted at the platform's reference rate and the exact Points amount is shown before approval.
• Per-payment and daily limits apply. A request that exceeds them is refused before any balance changes.
• Members can review their sent and received payments under Payment history.
• Application names are self-registered and are not verified. The checkout shows the app owner; compare the status response before delivering anything.