---
title: Price, deliver and capture
description: Build a service integration around explicit prices, supported payment methods and idempotent fulfillment.
---

## Publish an offer

Use [the dashboard merchant portal](/app?tab=merchants) to register your service and verify its domain before publishing offers. A free offer has a zero price. Paid offer prices use exact decimal USD strings and integer microcredits, with their credit face value shown alongside dollars.

## Check free account access

After registering and verifying the merchant domain, publish a zero-price offer and configure your service backend with its merchant ID and offer ID. Authenticate the requesting agent with AgentID independently.

The agent calls the agentsub API using a resource-bound agent access token for `https://api.agentsub.dev`:

```bash
curl https://api.agentsub.dev/v1/access/check \
  -H "Authorization: Bearer $AGENT_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"offerId":"YOUR_CONFIGURED_OFFER_ID"}'
```

The authenticated response identifies `agentIdentity.subject`, `agentIdentity.issuer`, `merchantId`, and `offerId`, alongside `allowed`, `paymentRequired`, and the shared account balance. No credits are charged for this check.

Your merchant backend must obtain the result from the authenticated agentsub API and match both AgentID subject and issuer against the identity it independently verified. Match `merchantId` and `offerId` against your configured service and offer. A browser-supplied response, another merchant’s offer, or a balance value alone is not proof of access. Grant free access only when `allowed` is `true` and `paymentRequired` is `false` for those matching identities and offer.

For paid offers, the check returns `allowed: false` and `paymentRequired: true`. That result does not grant entitlement or prove payment. Complete the voucher and payment workflow below before delivering paid service access. Frozen agents and offers outside an agent’s permissions are denied.

## Challenge and verify

Return a 402 payment challenge when payment authority is missing. List only the payment methods actually implemented and accepted by the offer. Verify the signed voucher against the issuer JWKS, audience, agent, offer, maximum amount and expiry before delivery.

## Capture once

Capture the authorized amount with a stable idempotency key. Retries must not double-charge or double-deliver. The workspace SDK exposes AcceptorClient capture and release helpers; service delivery requires verified spending authority and configured provider access.

[SDK](/fr/docs/sdk) · [Gateway API](/fr/reference) · [Payment methods](/fr/docs/payments).

## Signed delivery notifications

A verified merchant owner can configure an enabled HTTPS receiver on the merchant domain or a subdomain. [The actual webhook contract](/fr/events) describes `redemption.captured` and `redemption.released` notifications, their `ACS-Signature` header, stable event IDs, retry budget, and actual receipt logs. Configuration does not establish successful delivery; no historical events are backfilled. Verify the exact raw request body with the one-time webhook secret and deduplicate `eventId` before side effects. Delivery is at least once and can arrive out of order. Use the merchant portal to inspect actual pending, queued, delivered, or failed attempts.