Browser Pay

Browser Pay lets an Agent complete a merchant website’s card checkout using a payment credential issued by Clink. The merchant does not need to be registered with Clink. The Agent operates the merchant website; Clink handles the wallet, purchase authorization, and credential issuance. Before starting, connect to MCP and read its current business rules. The user must have authorized the purchase, including any budget limit. Check these conditions:

Payment card. The current wallet response’s agent_pay_support indicates card eligibility. The merchant or issuer may still decline the payment.
Merchant checkout. Your Agent can read the final total, fill the card form including embedded payment fields, submit payment, and inspect the merchant’s payment or order result.
User verification. The user can complete any required bank verification, such as 3-D Secure or a one-time code.

A platform that receives encrypted credentials also needs the decryption implementation.

The payment flow

Payment flow
When user action is required

When a valid purchase authorization covers the payment, get_credential can return the credential directly. Use credential.card as provided; decrypt only when the response contains key and payload.

If get_credential returns a REDIRECT_USER link, complete this flow, then return to the payment flow to use the credential.Wait for the returned setup Operation to complete, then repeat get_credential with the same checkout facts and selected paymentInstrumentId, if any. Do not pass the setup operation ID. Other SETUP_REQUIRED cases are described in step 2.

The diagram shows the successful path. If the card is never submitted, report NOT_SUBMITTED; if submission occurred but its result is unknown, report UNKNOWN.

1. Read the final checkout amount

Use the merchant checkout page’s final total, including shipping and tax. Do not use the product list price or treat the user’s maximum budget as the amount to charge. Obtain contact and delivery details from the user or their merchant account. Select the website’s card payment option and leave any option to save payment details disabled. If the user named a specific wallet card, obtain its paymentInstrumentId from a fresh get_account_state response and check agent_pay_support: true. Otherwise, omit the selector to use the default card.

2. Request a credential

The following is a tools/call request. For a checkout total of USD 12.50, send amount: 1250:

{
  "name": "get_credential",
  "arguments": {
    "merchantUrl": "https://shop.example.com/checkout",
    "merchantName": "Example Store",
    "amount": 1250,
    "currency": "USD"
  }
}

Required scopes are wallet:read, payment:execute, instruction:read, and instruction:write. Clink checks the chosen card and matches an active purchase authorization. If one covers the payment, the call can return the credential immediately. Otherwise, it can start a one-time authorization for this checkout. You do not need to list or create purchase authorizations before every Browser Pay call. Handle the actual response:

Response	Next step
`credential` is present	Continue to step 3.
`REDIRECT_USER` / `PASSKEY`	Give the user `next_action.params.redirect_url` to authorize this payment.
`REDIRECT_USER` / `PAYMENT_METHOD_SETUP`	Give the user the returned link to add or choose a card and authorize this payment.
`SETUP_REQUIRED` / `DEFAULT_CARD`	Show the returned `wallet_cards` by brand and last four digits. Let the user select a card for this checkout or choose to change their default.
`SETUP_REQUIRED` / `PURCHASE_INSTRUCTION`	Complete the purchase authorization setup for the returned card and amount, then request the credential again.

When a redirect has actor: "USER_DEVICE_ONLY", the user opens it on their own device. Do not open or preview it in the Agent’s browser. After presenting a Passkey or card setup link, wait for the same setup Operation:

{
  "name": "get_operation",
  "arguments": {
    "operationId": "<setup operation_id>",
    "maxWaitSeconds": 60
  }
}

Once setup is complete, repeat get_credential with the checkout facts. Do not pass the setup operationId. Preserve paymentInstrumentId on each call if the user selected a card for this checkout. If the user chose a new default instead, call set_default_card before repeating the request without that selector. Opening a link is not proof that authorization is complete. If the response still requires action, follow the current next_action.

3. Read or decrypt the credential

Inspect the returned shape rather than assuming every client receives the same form:

Shape	How to use it
`credential.card`	Card details are already available. Use this object; no decryption is required.
`credential.key` and `credential.payload`	Preserve both strings exactly and decrypt them using the credential decryption example.

Cloud platforms arrange their public key with Clink through an offline contact. See platform integration.

How payment credentials are protected

The current Visa flow uses a tokenized card number and a dynamic security code in the merchant’s card form. The tokenized number replaces the user’s original card number, and the dynamic security code has an expiry. Use the returned credential and its expiry information for this checkout. When a platform receives key and payload, the credential is additionally encrypted for its public key. Decrypt with the matching private key to read the card fields. This protects credential delivery; the purchase authorization confirmed with a passkey defines the permitted spending. A response containing credential.card is also subject to the authorization limits and credential expiry.

Keep payment identifiers

Keep these identifiers for reporting:

`confirm_result` argument	Source
`operationId`	`operation_id` from the `get_credential` response that issued the card; also `clientReferenceId` in the credential payload
`orderId`	Payload `orderId`, or `resources.payment_order_id`
`paymentExecutionDetailId`	Payload `paymentExecutionDetailId`, or `resources.payment_execution_detail_id`

orderId identifies Clink’s payment order; it is not the merchant’s order number. Keep the merchant’s order number separately if the merchant returns one.

A get_credential Operation with status: "SUCCEEDED" means the credential was issued. It does not mean the merchant was paid. get_operation never returns the credential and cannot independently verify the merchant’s payment result.

get_credential.amount and confirm_result.paidAmount use minor currency units. The credential payload’s amount uses major units: for USD 12.50, these are 1250 and 12.50 respectively. Convert according to the currency’s precision; do not multiply every currency by 100.

4. Fill and submit the merchant payment

Fill the returned card number, expiry, and security code into the card fields on this checkout, including payment provider fields embedded in the page. Match the expiry format expected by the form. Use the returned cardholderName and billingAddress when available; ask for missing billing information instead of inventing it. Use the credential within its validity period. The decrypted expiry information and ttlMinutes, when present, take precedence over the outer credential.expires_at estimate. Recheck the total immediately before submission:

If unchanged, submit and inspect the merchant’s result. The user completes any required 3-D Secure or one-time code step.
If changed, do not submit the old credential. Report NOT_SUBMITTED with failureReason: "AMOUNT_CHANGED", then request a credential for the new total within the user’s authorization.

Card details are for this checkout’s payment fields. Do not include them in chat, logs, or saved notes. Use credential.display to describe the card to the user.

5. Report the observed result

Call confirm_result for the Browser Pay payment using the identifiers from step 3. For an observed successful payment:

{
  "name": "confirm_result",
  "arguments": {
    "orderId": "<issued orderId>",
    "paymentExecutionDetailId": "<issued paymentExecutionDetailId>",
    "operationId": "<issuing operation_id>",
    "outcome": "SUCCEEDED",
    "paidAmount": 1250,
    "currency": "USD"
  }
}

Outcome	Use when
`SUCCEEDED`	The merchant page explicitly confirmed that payment succeeded.
`FAILED`	The merchant showed a payment failure after submission.
`NOT_SUBMITTED`	You did not submit the card, for example because the total changed, decryption failed, or the user cancelled. This outcome does not require clicking Pay first.
`UNKNOWN`	The card was submitted, but you could not establish the result.

Supply paidAmount and currency together when the success page shows the paid amount. Add failureReason only with FAILED or NOT_SUBMITTED. See the full parameter reference. For UNKNOWN, keep the payment identifiers and inspect the merchant’s existing order or payment result. Do not submit another payment. Report the final result before the returned report_deadline. A repeated report with the same outcome is safe; a conflicting final outcome is refused. Clink records the Agent’s report and returns an agent_reported_result message. The report is not independent confirmation from the merchant. Refunds for this flow are handled with the merchant. Give the user a brief result using only details observed on the merchant page. For example, when the page confirms these details:

Example Store confirmed payment of USD 12.50. Merchant order: EX-1042.

If no merchant order number was shown, omit it. Do not invent one or substitute Clink’s orderId.

Recovery without a duplicate purchase

Situation	Recovery
Credential request timed out, returned `issuance_incomplete`, or its response was lost before submission	Repeat `get_credential` with the same checkout facts and selected card. Before final reporting, Clink reuses the outstanding credential rather than creating another purchase.
Credential expired before submission	Repeat the same request to obtain a replacement for the same order. If `credential_unavailable` is returned, use the known identifiers to report `NOT_SUBMITTED` with `CREDENTIAL_EXPIRED`.
Decryption failed	Do not submit. Report `NOT_SUBMITTED`, using identifiers from `resources` if available. If identifiers are unavailable, read the issuing Operation and resolve the integration failure; do not invent IDs or start a new payment.
Result reporting failed or returned `result_reporting_unavailable`	Retry the same `confirm_result` arguments. Do not pay again.
A final result was already reported	The purchase is finished. A later `get_credential` call with the same facts starts a new purchase, so call it only for a newly authorized purchase.

confirm_result belongs only to Browser Pay. UCP Checkout and direct payments obtain their results through their own tools; do not report those payments through this endpoint. For field constraints and error codes, see Browser Pay tools and Operations and recovery.

Get Started

Integration

Agent Solutions

Configure & Launch

Guides

Finance

The payment flow

1. Read the final checkout amount

2. Request a credential

3. Read or decrypt the credential

How payment credentials are protected

Keep payment identifiers

4. Fill and submit the merchant payment

5. Report the observed result

Recovery without a duplicate purchase

​The payment flow

​1. Read the final checkout amount

​2. Request a credential

​3. Read or decrypt the credential

​How payment credentials are protected

​Keep payment identifiers

​4. Fill and submit the merchant payment

​5. Report the observed result

​Recovery without a duplicate purchase

The payment flow

1. Read the final checkout amount

2. Request a credential

3. Read or decrypt the credential

How payment credentials are protected

Keep payment identifiers

4. Fill and submit the merchant payment

5. Report the observed result

Recovery without a duplicate purchase