Location Management

A location represents a single store, branch, or business unit that belongs to a merchant. Every terminal, payment, and report ties back to a location, so creating it correctly keeps settlement and analytics clean.

Lifecycle

Phase	Typical call	What happens
Provision	POST /Merchants/{id}/locations	Returns a locationId used when creating terminals or pulling reporting data
Configure	PUT /Locations/{id}	Replace all editable fields including name, tenderTypes, business type, MCC values, ticket sizes, and address
Disable	PUT /Locations/{id}/enabled	Stops new payment activity while preserving location history for reporting and settlement
Operate	Use locationId across terminal creation, reporting, and reconciliation	Dashboards and settlement reports group transactions by location
Retire	DELETE /Locations/{id} once no active terminals remain	Permanently removes the location record

Hierarchy recap

Partner
└─ Merchant
   └─ Location
      └─ Terminal
         └─ Payment

Endpoints at a glance

Action	Method and path
Create location	POST /Merchants/{id}/locations
List locations	GET /Merchants/{id}/locations
Get location	GET /Locations/{id}
Update location	PUT /Locations/{id}
Disable location	PUT /Locations/{id}/enabled
Delete location	DELETE /Locations/{id}

Business types

The locationBusinessType field controls which payment connections are provisioned for the merchant during onboarding. Set this value carefully — it cannot be changed after boarding without a full application resubmission.

Value	Description	Payment connections provisioned
physical	Brick-and-mortar store or branch	Physical connections only. Virtual wallet connections (Klarna, USDC, Lightning, etc.) are not built. Virtual terminals using wallet or BNPL tenders will fail.
virtual	Online or remote business. Requires a website value.	Virtual wallet connections only. Physical terminal connections are not built.
both	Operates both physically and online	Both physical and virtual connections are provisioned. Supports all terminal types and tender configurations.

Important: If a merchant is boarded with locationBusinessType: "physical" and later needs to accept virtual wallet payments, the application must be resubmitted with "virtual" or "both". There is no post-boarding maintenance path to add connection types.

Best practices

Create under the correct merchant. Pass the correct merchantId so dashboards roll up by store.

Set the right business type before submission. The locationBusinessType value determines which payment connections are built at boarding time. If your merchant needs to accept virtual wallet tenders (Klarna, USDC, crypto, etc.), use "virtual" or "both". A "physical"-only boarding cannot support Virtual terminals.

Disable before delete. Use PUT /Locations/{id}/enabled to stop new payments before decommissioning a location.

Use consistent naming. A clear pattern such as city and store number helps support teams locate a store quickly.

Tender type inheritance. A terminal inherits tenderTypes from its parent location unless overridden, and a location inherits merchant defaults if tenderTypes is omitted at creation.

Related pages

• Create Location

• List Locations

• Get Location

• Update Location

• Delete Location