> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.runpayments.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.runpayments.io/_mcp/server.

## Hosted Payment Pages: Redirect After Payment

Hosted payment pages can now send your customer back to your own site after they pay, instead of ending on the Run success page. Set `success_redirect_url` for approved payments and `failure_redirect_url` for declined ones. Read more in the [Redirect after payment](/docs/guides/payments/hosted-payment-pages#redirect-after-payment) section of the Hosted Payment Pages guide.

### Endpoints updated

- [`POST /api/v1/hpp`](/reference/payments-api/create-hosted-payment-page): Accepts `success_redirect_url` and `failure_redirect_url`, and returns them in the response.
- [`PUT /api/v1/hpp/{hpp_client_id}`](/reference/payments-api/edit-hosted-payment-page): Accepts both fields. An omitted field keeps its stored value; `null` or `""` clears it.

### What to know

- Destinations must be `https://` URLs on a domain name, up to 1,000 characters. An invalid URL returns `400`.
- On redirect, `transaction_id` and `result` (`approved` or `declined`) are added to the query string.
- Vault and card-on-file pages never redirect, and one-time links are still disabled after an approved payment.

## Boarding API — Update a Merchant

You can now update a merchant application through the Boarding API while it is still in the edit window (`merchant_status` of `new` or `sent_for_signature`):

- [`PUT /boarding/v1/merchants/{merchant_id}`](/reference/reporting-boarding/boarding-api/update-merchant): Fully replace a merchant application, and optionally retract it (`merchant_status: "new"`) or (re)send it for signature (`merchant_status: "sent_for_signature"`) in the same request
- The request body is the same application schema as [Create a merchant](/reference/reporting-boarding/boarding-api/create-merchant). The typical flow is to `GET` the merchant, apply your changes, and `PUT` it back
- Signed applications are locked and return `409`

## Boarding API — Section Locks

New `section_locks` object on [Create a merchant](/reference/reporting-boarding/boarding-api/create-merchant), [Update a merchant](/reference/reporting-boarding/boarding-api/update-merchant), and [Get a single merchant](/reference/reporting-boarding/boarding-api/get-merchant):

- `section_locks.mode_of_transaction: true` locks `in_person_pct`, `online_pct`, and `telephone_pct` so the merchant cannot change them while completing the application
- A locked split must total exactly 100, otherwise the request returns `422`
- Merchants created from a locked application template start locked unless the request sets the lock explicitly
- On update, leaving `section_locks` out keeps the merchant's current lock state

## Boarding API — 3 Tier Pricing

The `three_tier` pricing type is now documented on [Create a merchant](/reference/reporting-boarding/boarding-api/create-merchant):

- Set `pricing.pricing_type` to `three_tier` and submit the effective rate for each tier in basis points: `qual_rate_bps`, `mid_rate_bps`, and `non_rate_bps`, with a per-item fee for each
- AMEX OptBlue tier rates (`amex_qual_rate_bps`, `amex_mid_rate_bps`, `amex_non_rate_bps` and their per-item fees) are required when `amex_program` is `amex_opt_blue`