Clink (ClinkBill): Payments and Agentic Commerce (2026)

A practical guide to Clink's global checkout, Merchant of Record service, billing, smart routing, agent payments, Skill Marketplace, and pricing.

·12 min read

Clink, available at ClinkBill.com, is a payments and billing platform built for software companies selling globally. It combines checkout, local payment methods, subscriptions, tax handling, fraud protection, payouts, and payment routing with a newer set of tools for AI agents that need to buy or sell digital services.

That breadth can make the product difficult to categorize. Clink is not only an agent wallet, and it is not simply another card gateway. Its standard offering is a Merchant of Record payment stack for human customers, while its agent products add programmable spending, automatic credit top-ups, integration skills, and a marketplace for paid agent capabilities.

This guide explains what each layer does, how a normal Clink payment works, what is available for agents, what it costs, and where the platform fits.

Info

The short version: Clink is most relevant to AI-native and SaaS teams that want one system for global checkout and recurring billing today, plus a path for authorized agents to transact on the same underlying payment infrastructure.

Clink sits between a product and the payment providers that move money. A merchant creates customers, products, prices, checkout sessions, subscriptions, and refunds through Clink. The platform can then manage checkout, route transactions, collect tax, handle payment failures, and return payment state through APIs and webhooks.

Under Clink's standard plan, it also acts as the Merchant of Record. That means Clink is the legal seller for the transaction and takes responsibility for areas such as payment processing, sales-tax or VAT calculation and remittance, fraud, chargebacks, compliance, and payouts. This is a materially different service from a raw gateway where the software company remains responsible for those obligations.

Clink currently presents four connected product areas:

  • Global Payments: Hosted Checkout, embeddable payment components, cards, wallets, local payment methods, multiple currencies, fraud controls, and 3D Secure.
  • Billing: Products and prices, subscriptions, trials, recurring invoices, plan changes, coupons, dunning, and a customer portal.
  • Smart Routing: Rules that distribute transactions across connected payment providers, fail over to backups, retry recoverable failures, or favor a lower-cost route.
  • Agentic Commerce: Agent wallets, constrained payments, automatic top-ups, AI-assisted merchant integration, and a reviewed Skill Marketplace.

The products share a billing and transaction model. That is important for teams that want agents and people to buy from the same catalog rather than maintaining a second ledger for machine customers.

A basic website payment follows a familiar server-controlled checkout flow:

  1. The customer chooses an item, and the merchant backend validates the product, quantity, and current price.
  2. The backend creates its own pending order before calling Clink.
  3. The backend creates a Clink Checkout Session and stores the returned sessionId against that local order.
  4. The customer pays through Clink's hosted or embedded interface.
  5. Clink creates an Order for each payment attempt and sends the result to the merchant's webhook.
  6. The merchant verifies the webhook, matches it to the local order, records the result idempotently, and fulfills only after confirmed success.

Clink's payment model documentation makes a useful distinction between three records: a Checkout Session is the temporary entry point, a Clink Order is the result of one payment attempt, and the merchant order is the business's own record of what should be fulfilled. One Session can produce multiple Orders if a buyer retries with another method.

That distinction prevents two common payment bugs. A customer returning to a successUrl is not proof that money arrived, and a Session marked completed does not necessarily mean an Order succeeded. Fulfillment should follow a signature-verified order.succeeded event or a server-side Order query that returns success.

Checkout and Integration Options

Clink offers three main ways to present checkout. They use the same server-side Session and webhook model, so a team can start with the simplest option and change the interface later.

| Checkout option | Customer experience | Best fit | |---|---|---| | Hosted Checkout | Redirect to a Clink-hosted payment page | Fastest first integration and the least frontend work | | JavaScript SDK | Redirect or mount the complete hosted checkout in an iframe | Apps that want an SDK-controlled flow without rebuilding checkout | | Elements | Embed Clink-managed payment inputs inside a merchant-designed page | Branded or multi-step checkout experiences |

The integration guide recommends Hosted Checkout as the default starting point. Elements gives more design control, but the merchant still needs a backend to calculate the amount and create the Session. Secret keys and final prices should never come from browser code.

Developers can work through the REST API, the official TypeScript SDK, @clink-ai/clink-js for redirect or embedded checkout, or @clink-ai/clink-elements for composable payment UI. Clink provides separate sandbox and production environments, with different dashboards, API hosts, and keys.

Products, Billing, and Subscriptions

Clink supports both inline and registered products. Inline products describe a one-time item and amount while creating the Checkout Session, which suits credit top-ups or custom purchases. Registered products and prices live in the catalog and are the required path for subscriptions.

The subscription layer includes:

  • Flat-rate and other recurring pricing models
  • Trials and configurable billing intervals
  • Multi-currency prices
  • Immediate or period-end plan changes with preview and proration support
  • Promotion codes and coupons
  • Renewal retries and past-due handling
  • A hosted customer portal for invoices, payment methods, cancellations, and plan changes
  • Test clocks for simulating renewals and lifecycle changes in the sandbox

A subscription can start through Checkout when a new customer needs to authorize a payment method, or through a server-side API when a Clink customer and usable payment instrument already exist. The subscription documentation treats payment state and customer entitlement as separate concerns: creating a subscription does not prove the first invoice was paid, and renewal access should be updated from verified invoice, Order, and subscription events.

For teams using the standard Merchant of Record plan, global tax calculation and remittance are included. Clink says its billing and tax coverage spans more than 50 jurisdictions; companies with unusual product, nexus, or invoicing requirements should confirm the exact scope during onboarding.

Global Payments and Smart Routing

Clink advertises support for more than 135 currencies and 100 local payment methods. Its current documented methods include cards, Apple Pay, Google Pay, Cash App Pay, iDEAL, BLIK, Pix, Alipay, WeChat Pay, GCash, Kakao Pay, PromptPay, QRIS, Touch 'n Go, and UPI. Availability can vary by merchant, customer location, currency, browser, and whether the payment is one-time or recurring.

The routing layer is designed for businesses that have outgrown a single processor. A merchant can connect external payment-provider accounts, including multiple accounts with the same provider, then configure which route should receive a transaction. Clink describes routing goals such as lowering processing cost, failing over to a backup gateway, and retrying failed payments.

Keeping the product catalog and subscription state above the individual processor can reduce the amount of application logic tied to one provider. It does not eliminate migration or reconciliation work, though. Before relying on this architecture, verify which providers, countries, payment methods, and transaction types are available for the merchant account.

Clink's agent story is easier to understand when separated into three workflows.

The open-source clink-integ-skills package is for an AI coding agent that is already editing a merchant's application. According to Clink's agent integration guide, the skill can inspect the project, generate a product catalog, write checkout and webhook routes, register a sandbox webhook, and return verification instructions.

This is developer automation, not an autonomous purchase. It produces the same merchant integration a person could write from the API docs. The business still decides what to sell, how to price it, when to fulfill it, and how refunds work. A human also needs to complete a sandbox checkout and verify that the application updated the right order.

2. An Agent Pays with a User-Controlled Wallet

Clink's Agentic Payment Skill is the buyer-side workflow. A user initializes a wallet, links a payment method through a secure page, and configures risk or spending controls. An agent can then discover products, initiate a permitted payment, monitor asynchronous results, and request a refund through the Clink CLI and skill.

The model is delegated rather than unrestricted. Card details stay in the payment vault, while the agent operates through payment instruments and authorization rules. Browser steps that require the user—such as account authorization, card setup, 3D Secure, or Passkey signing—remain user handoffs rather than actions the agent should silently complete.

For credit-based products, Clink also supports automatic top-ups. When the agent is projected to run out of merchant credits, it can trigger a funding flow within the user's configured limits and continue after the balance is restored. Clink calls this design “Harness Payment”: the agent can transact, but only inside boundaries enforced outside the model.

The public Agentic Payments page still labels the offering Early Access. Teams should therefore validate supported agents, authorization methods, currencies, failure recovery, refunds, and production limits rather than treating every demonstrated flow as generally available.

3. Merchants Publish Paid Skills

The Clink Skill Marketplace is a distribution layer for agent-callable products. A merchant uploads a ZIP containing SKILL.md, submits a version and listing, passes Clink's review, and explicitly publishes the approved package. Clink generates the public CLI command and installation prompt from the reviewed artifact.

Payment-enabled skills can sell credits, charge per use or subscription period, and accept tips. After a successful recharge, Clink sends an order.succeeded webhook; the merchant applies the purchased value to the correct account and returns an account-created or account-reloaded result. As with any payment webhook, signature verification, atomic idempotency, and reconciliation are essential.

The marketplace itself is live, while the broader agent-payment offering remains in Early Access. That makes it most relevant today to developers willing to work through a developing ecosystem rather than teams requiring a mature, universally supported agent-payment standard.

Clink publishes one standard Merchant of Record rate:

| Item | Published price | |---|---:| | Payment, MoR, billing, tax, fraud, compliance, and payout service | 3.9% + $0.30 per transaction | | Setup fee | $0 | | Monthly minimum | $0 | | Chargeback | $20 per dispute | | UPI transaction | 8% | | Payout fee for US entities | $5 flat | | Payout fee for Hong Kong entities | $15 flat |

The standard rate includes payment processing, Merchant of Record services, tax calculation and remittance, fraud and chargeback protection, compliance, and payouts, with no separate gateway or platform fee. Clink notes that final terms can vary with risk, business model, product category, dispute exposure, and compliance review.

Billing-only arrangements and dedicated Agentic Payment integrations use custom commercial terms. Marketplace fees, revenue sharing, refunds, and settlement terms are also not published as a universal rate. Confirm current details on the official pricing page before making a cost comparison.

The headline fee should be compared with other Merchant of Record providers, not only with low-cost payment gateways. A raw processor can have a lower transaction rate because tax registration, filings, disputes, routing, and merchant liability remain with the seller.

Consider Clink when:

  • You sell software, API usage, credits, or digital services internationally.
  • You want a Merchant of Record to take on tax, compliance, fraud, and chargeback operations.
  • Your product needs subscriptions and one-time usage purchases in one catalog.
  • Local payment methods or multiple payment providers are important to expansion.
  • You want an AI coding agent to automate much of the initial payment integration.
  • Agents are a genuine customer channel and need controlled payments or automatic credit top-ups.
  • You want to package a metered capability as a discoverable, paid agent skill.

Clink may be more infrastructure than a small product needs if it sells in one country, already has a reliable gateway, and does not need Merchant of Record services. A mature incumbent may also be a better fit when a team depends on a large integration ecosystem, a particular local entity model, or payment methods Clink has not enabled.

What to Evaluate Before Adopting It

Run a sandbox integration and verify the complete business flow, not only the checkout page:

  1. Coverage: Confirm the exact countries, currencies, payment methods, and recurring-payment combinations your customers need.
  2. Commercial model: Compare the complete MoR cost with tax, dispute, payout, foreign-exchange, refund, and support terms included.
  3. Order integrity: Create the local order first, calculate prices server-side, and fulfill only from verified payment state.
  4. Webhook resilience: Test duplicate delivery, out-of-order events, delayed events, invalid signatures, retries, and reconciliation after an outage.
  5. Subscription behavior: Exercise trials, failed renewals, recovery, upgrades, downgrades, proration, cancellation, and refunds with test clocks.
  6. Routing value: Measure approval rate and processing cost by market before assuming an additional processor improves either one.
  7. Agent controls: Test authorization boundaries, user handoffs, automatic top-up limits, auditability, refund behavior, and what happens when Early Access features are unavailable.
  8. Operational fit: Review settlement timing, reporting, data portability, support response, and the production verification process.

The Bottom Line

Clink's differentiator is the combination of conventional revenue infrastructure and agent-facing commerce. A merchant can use it for hosted checkout, subscriptions, local methods, tax, and routing even if no AI agent ever spends a dollar. Agent wallets, integration skills, automatic top-ups, and the Skill Marketplace then extend that same stack to software buyers and sellers.

That combination is promising for AI-native products whose usage does not fit a simple monthly seat. It also comes with two practical caveats: Merchant of Record economics should be compared with equivalent full-service platforms, and the agent-payment layer is still in Early Access. The right next step is a representative sandbox payment, followed by a careful test of the webhook, subscription, routing, and authorization behavior your product will actually depend on.

C
Clink

Global payments, billing, and controlled commerce for humans and AI agents

Tip

Start with one Hosted Checkout payment in the sandbox. Prove the local-order, verified-webhook, and fulfillment chain before adding Elements, subscriptions, smart routing, or agent-initiated spending.

clinkclinkbillpaymentsbillingagentic-commercemerchant-of-recordagents