Location Management

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 your settlement and analytics clean.

Lifecycle

Phase	Typical call(s)	What happens
Provision	POST /Merchants/{id}/locations	Service returns a locationId you will use whenever you create terminals or pull reporting data.
Configure	PUT /Locations/{id} to replace all editable fields	Set friendly name, tenderTypes, maxTransactionAmount, or correct the address.
Operate	Include locationId in terminal creation, reporting, and reconciliation APIs	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 & 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 right merchantId so dashboards roll up by store.

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

• Consistent naming – adopt a clear pattern (city + store #) so support teams locate a store quickly.

• Tender-type inheritance – a terminal inherits tenderTypes from its parent location unless you override them on the terminal object itself.

Child pages

• Create Location – request/response tables, sample cURL

• List Locations – filters, pagination, and cross-link to List Terminals

• Get / Update / Delete Location – field-level reference

• Changelog – location-specific updates and deprecations