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	Service returns a locationId that you will use whenever you create terminals or pull reporting data.
Configure	PUT /Locations/{id}	Replace all editable fields. Set friendly name, tenderTypes, business type, MCC values, ticket sizes, and address corrections.
Operate	Use locationId across terminal creation, reporting, and reconciliation	Dashboards and settlement reports group transactions by location.
Retire	Disable the location, then DELETE /Locations/{id} once no active terminals remain	Disabling preserves history while blocking new activity.

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}
Delete location	DELETE /Locations/{id}

Best practices

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

• Disable before delete. This prevents accidental new payments during decommissioning.

• 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 you override them on the terminal, and a location may inherit merchant defaults if you omit tenderTypes when creating it.

Child pages

• Create Location. Request and response tables with a sample cURL.

• List Locations. Response shape and client side filtering tips.

• Get, Update, Delete Location. Field level references.

• Changelog. Location specific updates and deprecations.