Ask Abraxas whether one payment action may proceed

Architecture

holder -> Abraxas hosted /partner/verify
Abraxas -> signed eligibility receipt
merchant server -> GET /api/receipts/{id}/public
merchant server -> AbraxasPartnerKit.evaluateFetchedReceipt
payment adapter -> issue action contract (type, scope, expiry, nonce)
payment adapter -> preflight authorize_checkout or authorize_recurring_payment
merchant -> its own checkout or billing flow
lifecycle / webhook -> re-fetch public receipt, never grant from the event body
browser <- { allowed, reason, payment_action_binding, expires_at }

Policy pack → hosted Partner Flow → minimum approved receipt → payment preflight → merchant payment flow → lifecycle or webhook re-check. A webhook body is never a payment grant.

Receipt verification is AbraxasPartnerKit plus GET /api/receipts/{id}/public. This adapter does not implement a second verifier.

Circle Arc testnet settlement stays a separate review → confirm → submit flow and requires confirm_testnet_transfer. This adapter never calls Circle or creates a transfer.

Action contract

The merchant server issues a contract with partner, policy and version, action type, a narrow payment scope, expiry, and a one-time durable nonce. Sandbox actions are authorize checkout and authorize recurring payment. An allowed result is not a charge.

Privacy contract

• Google sign in creates an Abraxas account. It does not prove age, identity, residency, or eligibility.
• A webhook event is not authorization. Fetch GET /api/receipts/{id}/public and verify the signed receipt on your server before granting access.
• An approved authorization is not a payment, transfer, charge, subscription, or settlement. The merchant or payment partner executes its own payment flow. Abraxas never moves funds.
• Partners receive only allow or deny, a safe reason code, payment action binding, and expiry.
• Browser responses must not include receipts, signatures, claims, PII, wallet data, payment details, or provider payloads.

Server side preflight

import { AbraxasPaymentAuthorizationAdapter } from "@/lib/partner/paymentAuthorization";

const adapter = new AbraxasPaymentAuthorizationAdapter({
  partnerId: process.env.ABRAXAS_PARTNER_ID!,
  policyId: process.env.ABRAXAS_POLICY_ID!,
  policyVersion: 1,
  requirePolicyVersion: true,
  environment: "sandbox",
});

export function startPaymentCheck(returnUrl: string) {
  return adapter.startPolicyVerification(returnUrl);
}

export async function authorizeCheckout(receiptId: string) {
  const contract = adapter.issueActionContract({
    action_type: "authorize_checkout",
    action_scope: "sandbox:checkout",
  });
  if ("ok" in contract && contract.ok === false) {
    return { allowed: false, reason: contract.reason };
  }
  const verified = await adapter.verifySignedReceipt(receiptId);
  // Client JSON is allow/deny, reason, payment action binding, and expiry only.
  return await adapter.preflight({ result: verified, contract });
}

export async function authorizeRecurring(receiptId: string) {
  const contract = adapter.issueActionContract({
    action_type: "authorize_recurring_payment",
    action_scope: "sandbox:recurring_payment",
  });
  if ("ok" in contract && contract.ok === false) {
    return { allowed: false, reason: contract.reason };
  }
  const verified = await adapter.verifySignedReceipt(receiptId);
  return await adapter.preflight({ result: verified, contract });
}

Studio: Integration Studio · Kit: Partner Integration Kit · Reference: Checkout authorization example

Future live payment partner integration

1. The merchant or payment partner remains the execution system. Abraxas only answers a preflight for one named payment action.
2. An allowed result is authorization to start the partner's own checkout or recurring billing flow. It is not a charge, capture, transfer, or settlement.
3. Production access stays on the reviewed Launchpad upgrade path. No self-serve live payment credentials from this adapter.
4. Pin partner_id, policy_id, and policy_version. Fail closed on draft, deprecated, missing, or mismatched versions.
5. Issue a server-authoritative action contract (type, narrow scope, expiry, one-time nonce) before each authorization.
6. Verify the current public receipt on the server. Do not trust callbacks, webhooks, or client flags.
7. Consume the durable nonce on the first permitted preflight. Replay the same nonce as deny.
8. Re-check expiry, revocation, policy version, partner binding, payment scope, and nonce replay before later grants.
9. Return only allow or deny, a safe reason, payment action binding, and expiry. Never return receipt or payment material.
10. Do not vault cards, store PANs, call Circle, create transfers, or move funds from Abraxas.
11. Keep Circle Arc testnet settlement on the explicit confirm_testnet_transfer path. Do not fold it into this adapter.
12. Integrate a live payment partner only after a written commerce agreement, production review, and named processor contract.