Onboard a Switcloud terminal

Onboard a Switcloud terminal

Create an estate, a minimum EMV configuration, and the POIConfig that binds them to a terminal.

1. Password-grant token. Returns access_token, token_type bearer, expires_in 3600.
2. create-merchant
3. merchant_id is required — omitting it is the most common 422 in this flow.
4. The terminal or COTS device. identifier and serial_number are both required and distinct.
5. A kernel parameter set. kernel, aid and tlv are shown in the provider's own Python sample.
6. create-emv-list
7. Join endpoint — two path ids, in order (list id then emv id).
8. emv_nominal_list_id is the working parameter set; emv_failsafe_list_id is the fallback and should be populated in production. This workflow sets only the nominal list, matching the provider's minimum example.
9. The join object a terminal fetches at runtime. The docs require at least an EMVConfig; bin_config_id, capk_list_id and cr_list_id are optional and can be added later (CAPKs are required in practice for offline data authentication).
10. Read the bundle back with expansion on. Without with_related=true a POIConfig holding a dangling reference looks fine; with it, bin_config / capk_list / cr_list / emv_config are inlined.

What you'll need to have ready

• username: Organization Admin email address.
• password
• merchant_name
• store_name
• store_address
• poi_name
• poi_identifier
• poi_serial_number
• poi_brand: One of UNDEFINED, SUNMI, CASTLES, PAX, SAMSUNG, GOOGLE.
• emv_technology_type: CONTACT or CONTACTLESS.

For your developer

Arazzo workflow switstack:onboard-a-terminal, 10 operations: token → create_merchant → create_store → create_poi → create_emv → create_emv_list → add_emv_to_emv_list → create_emv_config → create_poi_config → get_poi_config. Specs on APIs.io.