Accreditation Journeys — Overview

1. What is Accreditation?

Accreditation is the process by which a commercial establishment (merchant) becomes part of the Getnet network, enabling it to accept payments by card and other electronic means. During this process, registration data is collected, risk and compliance analysis is performed (qualification), the contracted commercial offerings are defined, and the formal order that consolidates all of this is created.

2. Journey Types

The Getnet platform supports two accreditation models, which differ mainly in who conducts the filling out of the information:
CharacteristicSelf-Service AccreditationAssisted Accreditation
Who fills in the dataThe merchant itself, in a self-service digital channelA Getnet agent / consultant
Human interactionMinimal — flow guided by the applicationHigh — agent guides the merchant
Entry pointOpen digital channel (open sea)Internal channel / back-office
Timing of the offerings showcaseBefore merchant creationAfter merchant creation
GET /offerings filterscountry + channel (optionally monthly_card_income + merchant_category_code + fiscal_type if the channel already has this information before displaying offerings)country + channel + monthly_card_income + merchant_category_code + fiscal_type
monthly_card_income in POST /merchantsNot required at creationSent at creation
MCC (merchant_category_code)Not used as a mandatory filterReturned in POST /merchants and used in GET /offerings
fiscal_typeOptional — used if available before registrationUsed as a filter in GET /offerings

3. Authentication — Prerequisite for Both Journeys

Every call to the Getnet platform requires a valid access token obtained via OAuth 2.0. The token must be renewed before it expires.
Text
[Your Application] ──POST /token──────────────────────► [Authentication API] (credentials in headers + body) ◄──200 OK { access_token, expires_in }── [Your Application] ──Request + Authorization: {access_token}──► [Other APIs] ◄──Operation response────────────────────────────────── ↺ Repeat POST /token when expires_in approaches its end.
information icon

📄 Full details at POST /token

4. Journey 1 — Self-Service Accreditation (Open Sea)

In this journey the merchant accesses a digital channel and conducts its own accreditation without the help of an agent. The flow below represents the happy path from start to finish.

4.1 Macro view of the flow

Text
[Authentication] │ ▼ [Offerings Showcase] ←── Merchant chooses a plan/offering │ ▼ [Step 0] Prior check — does the document already have an EC? │ no ▼ [Step 1] Merchant creation (minimum data) │ ▼ [Step 1.5] Zip code lookup + Shipping options │ ▼ [Step 2] Data complement (PUT /merchants) │ ▼ [Step 3] Qualification (risk analysis) │ approved ▼ [Step 4] Qualification result confirmed │ ▼ [Step 5-6] Assembling the order items (offerings → items) │ ▼ [Step 7] Bank data information │ ▼ [Step 8] Order creation → POST /orders │ ▼ [Step 8.5] Order update → PUT /orders/{id} *(when necessary)* │ ▼ [Step 9] Order validation → POST /orders/{id}/validation │ approved ▼ [Step 10] Order submission → PUT /orders/{id}/submit │ ▼ [Accreditation completed — order_number generated]

4.2 Step details

🔐 Authentication

Obtain the access_token as described in section 3 and include it in all subsequent calls.
information icon

📄 POST /token

🛍️ Offerings Showcase

Before starting the registration, query the offerings available for the channel and country. This allows the merchant to choose a plan before registering.

Text
Consumer ──GET /offerings?country=BR&channel={channel}──► Offerings API ◄── List of offerings (without acquiring fees) ── Consumer ──GET /offerings?priced_offering_id={id}──► Offerings API ◄── Single object with fees detailed by brand ── └─ {id} = priced_offering_id returned in the previous listing OR (in a single call) Consumer ──GET /offerings?country=BR&channel={channel}&show_acquirers=true──► Offerings API ◄── List of offerings with fees already included ──
information icon

📄 GET /offerings

Step 0 — Prior check (optional, but recommended)

Check whether the provided CPF/CNPJ already has a Commercial Establishment (EC) accredited with Getnet. If so, do not proceed with the registration.
Text
GET /establishment-contracts-basic/legal-document-number/{cpf_cnpj}/ec-accredited ├── accredited: true ──► Document already has an EC. Stop the flow. └── accredited: false ──► Can register. Proceed to Step 1.

Step 1 — Merchant creation (minimum data)

Create the merchant record with the minimum required information. The response returns the merchant_id, which will be used in all subsequent calls.
Text
POST /merchants │ Send: CPF/CNPJ + basic personal data + opt-ins (LGPD + terms) │ Returns: merchant_id + sub_status_steps (pending steps) │ └──► Save the merchant_id to use in the following steps.
information icon
⚠️ Save the returned merchant_id — it is required in all subsequent calls.
information icon

📄 POST /merchants

Step 1.5 — Zip code lookup and delivery options (when necessary)

Validate the zip code provided by the merchant and query the delivery options available for that address.

Text
GET /domains/zipcode/{postal_code} │ ├─► 200 — Zip code found │ └─► Pre-fill address fields │ Ask the merchant for: number and complement │ └─► 404 — Zip code not found └─► Inform the merchant that the entered zip code is invalid or was not found, and ask them to provide a new valid zip code before proceeding. GET /offerings/delivery-data?legal_document_number={doc}&postal_code={zip}&ids={offering_id_1},{offering_id_2} │ ├─ Required parameters: │ ├─ legal_document_number — merchant's CPF or CNPJ │ └─ postal_code — delivery address zip code │ ├─ Optional parameters: │ └─ ids — One or more offering IDs (offering_id or reference_id) separated by commas, │ to query the specific shipping for the products contained in those offering(s). │ └── Returns available delivery options (normal, express, scheduled)
information icon

📄 GET /offerings/delivery-data · GET /domains/zipcode/{postal_code}

Step 2 — Data complement (when necessary)

Get the current complete state of the merchant and send the complete payload updated with the complementary data.
Text
GET /merchants/{merchant_id} │ Change only the necessary fields in the returned payload │ PUT /merchants/{merchant_id} │ Send: income, net worth, addresses, business hours, etc.
information icon
⚠️ Never send a partial payload. The PUT replaces all merchant data. Always fetch the complete object with GET before modifying it.
information icon

📄 PUT /merchants/{merchant_id}

Step 3 — Qualification (risk and compliance analysis)

Trigger the merchant qualification. The response already contains the result — there is no need to perform an additional GET query to obtain it.
Text
POST /merchants/{merchant_id}/qualification │ └── Returns: report.recommended.status + report.details[]
information icon

📄 POST /merchants/{merchant_id}/qualification

Step 4 — Qualification result

Evaluate the report.recommended.status field returned by POST /merchants/{merchant_id}/qualification to decide how to proceed:
Text
report.recommended.status │ ├── "approved" ──► Merchant approved. │ Proceed with the accreditation normally. │ ├── "pending" ──► Merchant under manual review by the risk team. │ Proceed with the accreditation normally; │ the final result will be defined by the risk team. │ └── "reproved" ──► Merchant rejected. Will not be able to do business with Getnet. Check the reason in: report.details[*].detail_description
information icon

📄 GET /merchants/{merchant_id}/qualification

Steps 5 and 6 — Assembling the order items

For each offering selected by the merchant, map each offering item to an order item:

Text
For each selected offering: └─ For each item in offering.items[]: ├─ item_sequence_number = next global sequential number ├─ offering.priced_offering_id = offering.priced_offering_id (offering root) ├─ offering.smart_offering_id = offering.priced_offering_id (offering root) ├─ product = item.product (full copy) ├─ quantity = quantity informed by the customer (item.quantity is only the initial quantity suggested by the offering) ├─ settlement_period = item.settlement_period (if present) ├─ unit_price = item.unit_price (if present) └─ total_price = item.total_price (if present)

Step 6.5 — Assembling the delivery address (delivery_info)

With the zip code validated (Step 1.5) and the shipping type chosen by the merchant from the GET /offerings/delivery-data response, assemble the delivery_info object that will be sent in the POST /orders.
Text
delivery_info ├─ delivery_type = type selected by the merchant ("scheduled" / "normal" / "express") ├─ delivery_amount = delivery_methods[x].delivery_amount ├─ delivery_time = delivery_methods[x].delivery_time │ ├─ [if "normal" or "express"] │ └─ delivery_time_type = delivery_methods[x].delivery_time_type ("D" = days / "H" = hours) │ ├─ [if "scheduled"] │ ├─ recommended_delivery_period = period selected by the merchant ("morning" / "afternoon" / "night") │ ├─ period_grid = delivery_methods[x].period_grid[] entry corresponding to the period │ └─ delivery_time_type = null │ ├─ delivery_reference_point = reference point informed by the merchant (optional) │ └─ delivery_address = delivery address informed by the merchant ├─ street = street (returned by GET /domains/zipcode) ├─ number = number (informed by the merchant) ├─ complement = complement (informed by the merchant, optional) ├─ district = district (returned by GET /domains/zipcode) ├─ city = city (returned by GET /domains/zipcode) ├─ state = state (returned by GET /domains/zipcode) ├─ postal_code = zip code validated in Step 1.5 └─ country = "BR"

Step 7 — Bank data (banking domicile)

For each contracted brand, provide the bank account data where the merchant will receive the amounts.

Text
merchant_accounts[] — one item per contracted brand: ├─ brand = brand (visa / master / elo / amex / ...) ├─ merchant.merchant_id = merchant_id (Step 1) ├─ bank_account.bank.bank_code = bank's FEBRABAN code ├─ bank_account.bank_branch_code = branch ├─ bank_account.bank_account_number = account + digit ├─ bank_account.account_type = cc / pp ├─ payment_center = true / false └─ merchant_account_restriction = []
information icon

📄 Banks

Step 8 — Order creation

With all the data collected, create the formal accreditation order.

Before sending, calculate the totalization fields by summing the total_price of the items where product.product_type = "terminal", grouped by the product.pricing_model.pricing_type:
Text
total_fixed_price ← Σ total_price of terminals with pricing_type = "fixed_price" total_monthly_rent ← Σ total_price of terminals with pricing_type = "monthly_rent" total_affiliation_fee ← Σ total_price of terminals with pricing_type = "affiliation_fee" total_recurrent ← Σ total_price of terminals with pricing_type = "recurrent" total_payment_price ← Σ total_price of terminals with pricing_type = "payment_price" total_license ← Σ total_price of terminals with pricing_type = "license"
information icon
Items with a product_type other than terminal (e.g., composite, service) are not included in this calculation. Fields without corresponding terminals must be sent with a value of 0.
Text
POST /orders │ Send: merchant, delivery_info, items[], merchant_accounts[], total_fixed_price, total_monthly_rent, total_affiliation_fee, total_recurrent, total_payment_price, total_license │ Returns: order_id │ └──► Save the order_id to use in the following steps (validation, update and submission).
information icon
⚠️ Save the returned order_id — it is required in all subsequent calls (PUT /orders/{order_id}, POST /orders/{order_id}/validation, PUT /orders/{order_id}/submit).
information icon

📄 POST /orders

Step 8.5 — Order update (when necessary)

If it is necessary to correct or complement order data before submission, use PUT /orders/{order_id}.
Text
PUT /orders/{order_id} │ Send: complete order object (with the changes applied)
information icon
⚠️ Never send a partial payload. The PUT replaces all order data. Always send the complete object.
Important difference compared to PUT /merchants/{merchant_id}:
BehaviorMerchantOrder
Enrichment✅ Yes — the platform adds information to the object after creation❌ No — the order data is exactly what the channel sent in the POST /orders
GET before PUTMandatory — to get the enriched data and not accidentally overwrite itOptional — if the channel stores the order locally, the data is identical to the platform
  • If the channel stores the order in its domain: just modify or increment the fields in the local structure and send the PUT with the complete object — there is no need to call GET /orders/{order_id} beforehand.
  • If the channel does not store the order: call GET /orders/{order_id} (using the order_id returned in the POST /orders), apply the changes and send the PUT.

After any change to the items, recalculate the totalization fields as in Step 8.

information icon

📄 PUT /orders/{order_id}

Step 9 — Order validation (recommended)

Before submitting, validate the order to identify and correct any issues.

Text
POST /orders/{order_id}/validation │ ├── report.recommended.status = "approved" ──► Proceed to submission. │ └── report.recommended.status = "reproved" ──► Check and correct: report.details[].detail_description
information icon
⚠️ After submission (Step 10) the order can no longer be corrected. Use this step as a safeguard.
information icon

📄 POST /orders/{order_id}/validation

Step 10 — Order submission

Submit the order after merchant confirmation. This is the final step.

Text
PUT /orders/{order_id}/submit │ ├── Rejected ──► error.report.recommended = "reproved" │ Check: report.details[].detail_description │ └── Submitted ──► situation.status = "submitted" order_number generated — use it to track the order │ ├─ To check whether the order was approved: │ GET /orders?order_number={order_number} └─ Or configure a webhook to receive status notifications.
information icon

📄 PUT /orders/{order_id}/submit

5. Journey 2 — Assisted Accreditation

In this journey, a Getnet agent or consultant conducts the accreditation on behalf of the merchant. The main structural difference compared to the self-service journey is the order of the calls: here the merchant is created first and, with the returned merchant_category_code (MCC), the offerings showcase is queried in a personalized way for that business profile.

5.1 Macro view of the flow

Text
[Authentication] │ ▼ [Step 0] Prior check — does the document already have an EC? │ no ▼ [Step 1] Merchant creation (minimum data + monthly_card_income) │ └── Returns: merchant_id + MCC ▼ [Offerings Showcase] ←── Filtering with MCC and the merchant's monthly income │ ▼ [Step 1.5] Zip code lookup + Shipping options │ ▼ [Step 2] Data complement (PUT /merchants) │ ▼ [Step 3] Qualification (risk analysis) │ approved ▼ [Step 4] Qualification result confirmed │ ▼ [Steps 5-6] Assembling the order items (offerings → items) │ ▼ [Step 7] Bank data information │ ▼ [Step 8] Order creation → POST /orders │ ▼ [Step 8.5] Order update → PUT /orders/{id} *(when necessary)* │ ▼ [Step 9] Order validation → POST /orders/{id}/validation │ approved ▼ [Step 10] Order submission → PUT /orders/{id}/submit │ ▼ [Accreditation completed — order_number generated]

5.2 Step details

🔐 Authentication

Identical to the self-service journey. Obtain the access_token as described in section 3.
information icon

📄 POST /token

Step 0 — Prior check (optional, but recommended)

Identical to the self-service journey.

Text
GET /establishment-contracts-basic/legal-document-number/{cpf_cnpj}/ec-accredited ├── accredited: true ──► Document already has an EC. Stop the flow. └── accredited: false ──► Can register. Proceed to Step 1.

Step 1 — Merchant creation (minimum data)

In this journey, the monthly_card_income (monthly card revenue) is sent at creation. The response includes the merchant_category_code (MCC), which must be saved to filter the offerings appropriate to the business profile.
Text
POST /merchants │ Send: CPF/CNPJ + basic personal data + monthly_card_income + opt-ins (LGPD + terms) │ Returns: merchant_id sub_status_steps (pending steps) economic_activity_profile.merchant_category_code ← MCC │ └──► Save the merchant_id and the MCC to use in the following steps.
information icon
⚠️ Save both the merchant_id and the merchant_category_code — both are used in the following calls.
information icon

📄 POST /merchants

🛍️ Offerings Showcase (after merchant creation)

Unlike the self-service journey, here the offerings query occurs after merchant creation, since it uses the MCC and the monthly income to return only the offerings eligible for that profile.
Text
GET /offerings?country=BR&channel={channel}&monthly_card_income={monthly_income}&merchant_category_code={mcc}&fiscal_type={fiscal_type} └── Returns list of offerings (without acquiring fees) GET /offerings?priced_offering_id={id} └── Returns a single object with fees detailed by brand └─ {id} = priced_offering_id returned in the previous listing OR (in a single call) GET /offerings?country=BR&channel={channel}&monthly_card_income={monthly_income}&merchant_category_code={mcc}&fiscal_type={fiscal_type}&show_acquirers=true └── Returns list of offerings with fees already included
information icon

📄 GET /offerings

Steps 1.5 to 10 — Complement, Qualification, Order and Submission

From here on, the flow is identical to the self-service journey. See the corresponding steps in section 4.2:
StepDescriptionLink
1.5Zip code lookup and delivery options→ Step 1.5
2Data complement via PUT /merchants→ Step 2
3Trigger qualification→ Step 3
4Check qualification result→ Step 4
5-6Assembling the order items→ Steps 5 and 6
7Provide bank data→ Step 7
8Create order→ Step 8
8.5Update order (when necessary)→ Step 8.5
9Validate order→ Step 9
10Submit order→ Step 10

5.3 Differences compared to Self-Service Accreditation

AspectSelf-ServiceAssisted
Who operatesThe merchant itselfAgent / consultant
Timing of the offerings showcaseBefore merchant creationAfter merchant creation
Showcase filterscountry + channel (optionally monthly_card_income + merchant_category_code + fiscal_type if available)country + channel + monthly_card_income + merchant_category_code + fiscal_type
monthly_card_income in POST /merchantsNot required at creationSent at creation
MCC (merchant_category_code)Not used as a mandatory filterReturned in POST /merchants and used in GET /offerings
fiscal_typeOptional — used if availableUsed as a filter in GET /offerings

6. Quick Reference of Endpoints by Step

Self-Service Accreditation

StepMethodEndpointDocumentation
AuthenticationPOST/tokenPOST /token
Offerings showcaseGET/offeringsGET /offerings
0 — Prior checkGET/establishment-contracts-basic/legal-document-number/{doc}/ec-accreditedGET /establishment-contracts-basic/legal-document-number/{doc}/ec-accredited
1 — Merchant creationPOST/merchantsPOST /merchants
1.5 — Zip code lookupGET/domains/zipcode/{postal_code}GET /domains/zipcode/{postal_code}
1.5 — Delivery optionsGET/offerings/delivery-dataGET /offerings/delivery-data
2 — Get current merchantGET/merchants/{merchant_id}GET /merchants/{merchant_id}
2 — Complement dataPUT/merchants/{merchant_id}PUT /merchants/{merchant_id}
3 — Trigger qualificationPOST/merchants/{merchant_id}/qualificationPOST /merchants/{merchant_id}/qualification
4 — Query qualificationGET/merchants/{merchant_id}/qualificationGET /merchants/{merchant_id}/qualification
6.5 — Assemble delivery_info—(local assembly with data from GET /offerings/delivery-data + zip code)→ Step 6.5
8 — Create orderPOST/ordersPOST /orders
8.5 — Update orderPUT/orders/{order_id}PUT /orders/{order_id}
9 — Validate orderPOST/orders/{order_id}/validationPOST /orders/{order_id}/validation
10 — Submit orderPUT/orders/{order_id}/submitPUT /orders/{order_id}/submit

Assisted Accreditation

StepMethodEndpointDocumentation
AuthenticationPOST/tokenPOST /token
0 — Prior checkGET/establishment-contracts-basic/legal-document-number/{doc}/ec-accreditedGET /establishment-contracts-basic/legal-document-number/{doc}/ec-accredited
1 — Merchant creationPOST/merchantsPOST /merchants
Offerings showcaseGET/offerings?monthly_card_income={val}&merchant_category_code={mcc}&fiscal_type={fiscal_type}GET /offerings
1.5 — Zip code lookupGET/domains/zipcode/{postal_code}GET /domains/zipcode/{postal_code}
1.5 — Delivery optionsGET/offerings/delivery-dataGET /offerings/delivery-data
2 — Get current merchantGET/merchants/{merchant_id}GET /merchants/{merchant_id}
2 — Complement dataPUT/merchants/{merchant_id}PUT /merchants/{merchant_id}
3 — Trigger qualificationPOST/merchants/{merchant_id}/qualificationPOST /merchants/{merchant_id}/qualification
4 — Query qualificationGET/merchants/{merchant_id}/qualificationGET /merchants/{merchant_id}/qualification
6.5 — Assemble delivery_info—(local assembly with data from GET /offerings/delivery-data + zip code)→ Step 6.5
8 — Create orderPOST/ordersPOST /orders
8.5 — Update orderPUT/orders/{order_id}PUT /orders/{order_id}
9 — Validate orderPOST/orders/{order_id}/validationPOST /orders/{order_id}/validation
10 — Submit orderPUT/orders/{order_id}/submitPUT /orders/{order_id}/submit

7. Cross-cutting Concepts

merchant_id

Unique identifier generated in the POST /merchants. It must be persisted and used in all subsequent calls of the accreditation cycle.

priced_offering_id

Identifier of an offering with prices detailed by brand. Obtained from the Offerings API and used when assembling the order items.

order_id and order_number

  • order_id: internal identifier generated in the POST /orders. Used for validation and submission.
  • order_number: generated after successful submission. Used by the merchant to track the logistical status of the order.

Qualification

Risk and compliance analysis process that verifies whether the merchant can be accredited. It can be synchronous (200 response) or asynchronous (202 response + polling via GET).

Banking domicile

Bank account(s) where the merchant will receive the transaction settlements. It must be provided per contracted brand.

information icon

📄 Banks · Centralizers

On this page

Accreditation Journeys — Overview