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:
| Characteristic | Self-Service Accreditation | Assisted Accreditation |
|---|---|---|
| Who fills in the data | The merchant itself, in a self-service digital channel | A Getnet agent / consultant |
| Human interaction | Minimal — flow guided by the application | High — agent guides the merchant |
| Entry point | Open digital channel (open sea) | Internal channel / back-office |
| Timing of the offerings showcase | Before merchant creation | After merchant creation |
| GET /offerings filters | country + 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 /merchants | Not required at creation | Sent at creation |
MCC (merchant_category_code) | Not used as a mandatory filter | Returned in POST /merchants and used in GET /offerings |
fiscal_type | Optional — used if available before registration | Used 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] ──600;">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 600;">POST /token when expires_in approaches its end.
text
[Your Application] ──600;">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 600;">POST /token when expires_in approaches its end.
📄 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 600;">options
│
▼
[Step 2] Data complement (600;">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 → 600;">POST /orders
│
▼
[Step 8.5] Order update → 600;">PUT /orders/{id} *(when necessary)*
│
▼
[Step 9] Order validation → 600;">POST /orders/{id}/validation
│ approved
▼
[Step 10] Order submission → 600;">PUT /orders/{id}/submit
│
▼
[Accreditation completed — order_number generated]
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 600;">options
│
▼
[Step 2] Data complement (600;">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 → 600;">POST /orders
│
▼
[Step 8.5] Order update → 600;">PUT /orders/{id} *(when necessary)*
│
▼
[Step 9] Order validation → 600;">POST /orders/{id}/validation
│ approved
▼
[Step 10] Order submission → 600;">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.🛍️ 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 ──600;">GET /offerings?country=BR&channel={channel}──► Offerings API
◄── List of offerings (without acquiring fees) ──
Consumer ──600;">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 ──600;">GET /offerings?country=BR&channel={channel}&show_acquirers=true──► Offerings API
◄── List of offerings with fees already included ──
text
Consumer ──600;">GET /offerings?country=BR&channel={channel}──► Offerings API
◄── List of offerings (without acquiring fees) ──
Consumer ──600;">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 ──600;">GET /offerings?country=BR&channel={channel}&show_acquirers=true──► Offerings API
◄── List of offerings with fees already included ──
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
600;">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.
text
600;">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
600;">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.
text
600;">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.
⚠️ Save the returnedmerchant_id— it is required in all subsequent calls.
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
600;">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.
600;">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 600;">options (normal, express, scheduled)
text
600;">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.
600;">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 600;">options (normal, express, scheduled)
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
600;">GET /merchants/{merchant_id}
│
Change only the necessary fields in the returned payload
│
600;">PUT /merchants/{merchant_id}
│
Send: income, net worth, addresses, business hours, etc.
text
600;">GET /merchants/{merchant_id}
│
Change only the necessary fields in the returned payload
│
600;">PUT /merchants/{merchant_id}
│
Send: income, net worth, addresses, business hours, etc.
⚠️ Never send a partial payload. ThePUTreplaces all merchant data. Always fetch the complete object withGETbefore modifying it.
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
600;">POST /merchants/{merchant_id}/qualification
│
└── Returns: report.recommended.status + report.details[]
text
600;">POST /merchants/{merchant_id}/qualification
│
└── Returns: report.recommended.status + report.details[]
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
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
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)
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 600;">GET /domains/zipcode)
├─ number = number (informed by the merchant)
├─ complement = complement (informed by the merchant, optional)
├─ district = district (returned by 600;">GET /domains/zipcode)
├─ city = city (returned by 600;">GET /domains/zipcode)
├─ state = state (returned by 600;">GET /domains/zipcode)
├─ postal_code = zip code validated in Step 1.5
└─ country = "BR"
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 600;">GET /domains/zipcode)
├─ number = number (informed by the merchant)
├─ complement = complement (informed by the merchant, optional)
├─ district = district (returned by 600;">GET /domains/zipcode)
├─ city = city (returned by 600;">GET /domains/zipcode)
├─ state = state (returned by 600;">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 = []
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 = []
📄 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"
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"
Items with aproduct_typeother thanterminal(e.g.,composite,service) are not included in this calculation. Fields without corresponding terminals must be sent with a value of0.
text
600;">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).
text
600;">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).
⚠️ Save the returnedorder_id— it is required in all subsequent calls (PUT /orders/{order_id},POST /orders/{order_id}/validation,PUT /orders/{order_id}/submit).
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
600;">PUT /orders/{order_id}
│
Send: complete order object (with the changes applied)
text
600;">PUT /orders/{order_id}
│
Send: complete order object (with the changes applied)
⚠️ Never send a partial payload. ThePUTreplaces all order data. Always send the complete object.
Important difference compared to
PUT /merchants/{merchant_id}:| Behavior | Merchant | Order |
|---|---|---|
| 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 PUT | Mandatory — to get the enriched data and not accidentally overwrite it | Optional — 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
PUTwith the complete object — there is no need to callGET /orders/{order_id}beforehand. - If the channel does not store the order: call
GET /orders/{order_id}(using theorder_idreturned in thePOST /orders), apply the changes and send thePUT.
After any change to the items, recalculate the totalization fields as in Step 8.
Step 9 — Order validation (recommended)
Before submitting, validate the order to identify and correct any issues.
text
600;">POST /orders/{order_id}/validation
│
├── report.recommended.status = "approved" ──► Proceed to submission.
│
└── report.recommended.status = "reproved" ──► Check and correct:
report.details[].detail_description
text
600;">POST /orders/{order_id}/validation
│
├── report.recommended.status = "approved" ──► Proceed to submission.
│
└── report.recommended.status = "reproved" ──► Check and correct:
report.details[].detail_description
⚠️ After submission (Step 10) the order can no longer be corrected. Use this step as a safeguard.
Step 10 — Order submission
Submit the order after merchant confirmation. This is the final step.
text
600;">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:
│ 600;">GET /orders?order_number={order_number}
└─ Or configure a webhook to receive status notifications.
text
600;">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:
│ 600;">GET /orders?order_number={order_number}
└─ Or configure a webhook to receive status notifications.
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 600;">options
│
▼
[Step 2] Data complement (600;">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 → 600;">POST /orders
│
▼
[Step 8.5] Order update → 600;">PUT /orders/{id} *(when necessary)*
│
▼
[Step 9] Order validation → 600;">POST /orders/{id}/validation
│ approved
▼
[Step 10] Order submission → 600;">PUT /orders/{id}/submit
│
▼
[Accreditation completed — order_number generated]
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 600;">options
│
▼
[Step 2] Data complement (600;">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 → 600;">POST /orders
│
▼
[Step 8.5] Order update → 600;">PUT /orders/{id} *(when necessary)*
│
▼
[Step 9] Order validation → 600;">POST /orders/{id}/validation
│ approved
▼
[Step 10] Order submission → 600;">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.Step 0 — Prior check (optional, but recommended)
Identical to the self-service journey.
text
600;">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.
text
600;">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
600;">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.
text
600;">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.
⚠️ Save both themerchant_idand themerchant_category_code— both are used in the following calls.
🛍️ 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
600;">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)
600;">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)
600;">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
text
600;">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)
600;">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)
600;">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
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:
| Step | Description | Link |
|---|---|---|
| 1.5 | Zip code lookup and delivery options | → Step 1.5 |
| 2 | Data complement via PUT /merchants | → Step 2 |
| 3 | Trigger qualification | → Step 3 |
| 4 | Check qualification result | → Step 4 |
| 5-6 | Assembling the order items | → Steps 5 and 6 |
| 7 | Provide bank data | → Step 7 |
| 8 | Create order | → Step 8 |
| 8.5 | Update order (when necessary) | → Step 8.5 |
| 9 | Validate order | → Step 9 |
| 10 | Submit order | → Step 10 |
5.3 Differences compared to Self-Service Accreditation
| Aspect | Self-Service | Assisted |
|---|---|---|
| Who operates | The merchant itself | Agent / consultant |
| Timing of the offerings showcase | Before merchant creation | After merchant creation |
| Showcase filters | country + 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 /merchants | Not required at creation | Sent at creation |
MCC (merchant_category_code) | Not used as a mandatory filter | Returned in POST /merchants and used in GET /offerings |
fiscal_type | Optional — used if available | Used as a filter in GET /offerings |
6. Quick Reference of Endpoints by Step
Self-Service Accreditation
| Step | Method | Endpoint | Documentation |
|---|---|---|---|
| Authentication | POST | /token | POST /token |
| Offerings showcase | GET | /offerings | GET /offerings |
| 0 — Prior check | GET | /establishment-contracts-basic/legal-document-number/{doc}/ec-accredited | GET /establishment-contracts-basic/legal-document-number/{doc}/ec-accredited |
| 1 — Merchant creation | POST | /merchants | POST /merchants |
| 1.5 — Zip code lookup | GET | /domains/zipcode/{postal_code} | GET /domains/zipcode/{postal_code} |
| 1.5 — Delivery options | GET | /offerings/delivery-data | GET /offerings/delivery-data |
| 2 — Get current merchant | GET | /merchants/{merchant_id} | GET /merchants/{merchant_id} |
| 2 — Complement data | PUT | /merchants/{merchant_id} | PUT /merchants/{merchant_id} |
| 3 — Trigger qualification | POST | /merchants/{merchant_id}/qualification | POST /merchants/{merchant_id}/qualification |
| 4 — Query qualification | GET | /merchants/{merchant_id}/qualification | GET /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 order | POST | /orders | POST /orders |
| 8.5 — Update order | PUT | /orders/{order_id} | PUT /orders/{order_id} |
| 9 — Validate order | POST | /orders/{order_id}/validation | POST /orders/{order_id}/validation |
| 10 — Submit order | PUT | /orders/{order_id}/submit | PUT /orders/{order_id}/submit |
Assisted Accreditation
| Step | Method | Endpoint | Documentation |
|---|---|---|---|
| Authentication | POST | /token | POST /token |
| 0 — Prior check | GET | /establishment-contracts-basic/legal-document-number/{doc}/ec-accredited | GET /establishment-contracts-basic/legal-document-number/{doc}/ec-accredited |
| 1 — Merchant creation | POST | /merchants | POST /merchants |
| Offerings showcase | GET | /offerings?monthly_card_income={val}&merchant_category_code={mcc}&fiscal_type={fiscal_type} | GET /offerings |
| 1.5 — Zip code lookup | GET | /domains/zipcode/{postal_code} | GET /domains/zipcode/{postal_code} |
| 1.5 — Delivery options | GET | /offerings/delivery-data | GET /offerings/delivery-data |
| 2 — Get current merchant | GET | /merchants/{merchant_id} | GET /merchants/{merchant_id} |
| 2 — Complement data | PUT | /merchants/{merchant_id} | PUT /merchants/{merchant_id} |
| 3 — Trigger qualification | POST | /merchants/{merchant_id}/qualification | POST /merchants/{merchant_id}/qualification |
| 4 — Query qualification | GET | /merchants/{merchant_id}/qualification | GET /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 order | POST | /orders | POST /orders |
| 8.5 — Update order | PUT | /orders/{order_id} | PUT /orders/{order_id} |
| 9 — Validate order | POST | /orders/{order_id}/validation | POST /orders/{order_id}/validation |
| 10 — Submit order | PUT | /orders/{order_id}/submit | PUT /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 thePOST /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.
📄 Banks · Centralizers
On this page
Accreditation Journeys — Overview