# Operate: Profile configuration

The business profile is the unit that governs payments. Return URLs, webhook endpoints, authentication and capture defaults all hang off it, and a merchant account can hold several — commonly one per brand, region or environment. Almost every "why did it behave like that?" question about a payment is answered by the profile it was created under.

## What this page covers
- Listing the profiles on the account (`GET /account/{account_id}/business_profile`)
- Reading one in full (`GET /account/{account_id}/business_profile/{profile_id}`)
- Updating it (`POST /account/{account_id}/business_profile/{profile_id}`)
- A field reference for the settings that change how payments behave

## Finding the ids
The profile endpoints need a merchant (account) id and a profile id in their paths. Neither is in the client configuration, and `/accounts/list` is not available to a merchant API key. The reliable source is a recent payment: `GET /payments/list?limit=1` returns both `merchant_id` and `profile_id`. This page does that automatically and leaves both editable.

## Fields worth knowing

| Field | Effect |
|---|---|
| `return_url` | Where shoppers land after a redirect when the payment does not set its own |
| `webhook_details` | The endpoint and event subscriptions — see [Webhooks](/operate/webhooks.md) |
| `force_3ds_challenge` | Forces a challenge rather than allowing frictionless authentication |
| `is_connector_agnostic_mit_enabled` | Lets stored credentials be charged through a different connector than the one that created them |
| `collect_billing_details_from_wallet_connector` | Whether wallet payments return the billing address the wallet holds |
| `always_request_extended_authorization` | Requests an extended authorisation hold on every payment |
| `payment_response_hash_key` | Signs redirect responses so you can verify they came from Peach |
| `redirect_to_merchant_with_http_post` | Returns the shopper by POST instead of GET |

## Key concepts
- **Updates are partial.** Send only the fields you are changing; anything omitted keeps its current value. Start from the retrieve response and edit down.
- **This is shared configuration.** A profile update affects every payment created under it, including other people's testing on the same sandbox account. Overwriting `webhook_details` will silently redirect deliveries someone else may be watching.
- The `profile_id` a payment was created under is on the payment itself, which is how you work backwards from behaviour to configuration.

## Related
- [Operate: webhooks](/operate/webhooks.md): the `webhook_details` half of the profile, with a live delivery feed
- [Operate: transactions](/operate/transactions.md): inspect a payment and see which profile it used
- [API reference](/playground.md): every endpoint, with the OpenAPI reference beside it

---

Interactive version: https://playground.peachpayments.com/operate/profile