Sample Payload
Got it. Let’s update the Sample Payload page to use that feeInformation structure and avoid any outdated fee fields. Here’s the full updated page you can paste into GitBook (no dividers, no source references).
Sample Payload
This page provides example request and response bodies for the merchant onboarding APIs. Use these examples as a starting point for building and testing your integration.
Examples are shown for:
Full application:
POST /merchant-onboarding/applicationMinimal or “empty” application:
POST /merchant-onboarding/application-shortCommon response:
MerchantOnboardingResponseA live-style
feeInformationblock from a Get Status result
Adjust field values and structures to match your program configuration and the schemas in the API reference.
Full application example
A full application is used when your system already has most of the merchant’s information and you want to prefill the onboarding package. The signer mostly reviews and confirms the details.
Request example
POST /merchant-onboarding/application
Authorization: Bearer {access_token}
Content-Type: application/json
Accept: application/jsonResponse example
In your integration you should store at least applicationId and envelopeId so you can retrieve status later and correlate with your internal records.
Minimal or “empty” application example
A minimal or empty application is used when you want to collect only basic identifiers and signer information up front and let the hosted onboarding flow collect most of the remaining data. You still must supply fee information somewhere in your program, because fees are not editable by the signer.
Request example
In this pattern, the hosted onboarding experience will prompt the signer for:
Legal and registered business details
Ownership and control information
Additional addresses and contact information
Banking and settlement details
Any required supporting documents
Your program configuration must ensure that fees are known for this merchant, even though they may not be present in this minimal request body.
Response example
The response uses the same MerchantOnboardingResponse model as the full application. Store applicationId and envelopeId and use applicationId when calling the status, webhook, or resend related operations.
Status and follow up example
After submitting either type of application, you can retrieve details using the status endpoint. A typical status response might look like this:
In this example, the feeInformation block reflects a live-style representation of settlement fees, crypto fees, and digital wallet fees for Klarna in-store and online. Your program configuration controls which tenders and fee types appear here and what the actual sellRate and isBilledByPartner values are.
How to adapt these payloads
When building your integration:
Start from the full application example and remove or adjust fields that are not applicable to your program.
Use your own partner id, merchant ids, and realistic addresses, phone numbers, and URLs.
Confirm required fields and enumerations for your environment in the API reference models.
Treat
feeInformationin the status response as the source of truth for how fees are modeled and displayed for your merchants.For minimal applications, keep the request body small, but make sure your program defines how fee information is configured and exposed, since the signer cannot edit fees.
These examples are intended to help you quickly get a working request and response flow in your sandbox before you refine the structures for production.
Last updated