Direct Merchant vs. Merchant of Record (MoR) Payouts

Pockyt supports two payout integration models: Direct Merchant and Merchant of Record (MoR). Both models use the same payout API endpoints — the difference is in the entity structure and how payees are associated with merchants.

This guide explains when to use each model and what changes at the API level.

Integration Models

Direct Merchant

A single merchant manages its own payouts through Pockyt. The merchant registers payees, creates payout accounts, and executes payouts directly.

Merchant (Pockyt Customer) → Payees

Merchant of Record (MoR)

A parent merchant — the Merchant of Record — manages payouts on behalf of one or more Payors (sub-merchants). This model is designed for Financial Institutions, Payment Service Providers, and platforms that provide payment services to other businesses.

For example: a large PSP is the Merchant of Record in Pockyt. Other companies that use the PSP's payment infrastructure are registered as Payors. Each Payor's payees are associated with that Payor through the payorNo parameter.

Merchant of Record (Pockyt Customer) → Payor A (sub-merchant) → Payees
                                     → Payor B (sub-merchant) → Payees
                                     → Payor C (sub-merchant) → Payees

🚧

Pre-requisites

API Credentials: Obtain merchantNo, storeNo, and API secret from Pockyt.

Payor Registration (MoR only): If integrating as a Merchant of Record, your Payors must be registered and assigned a payorNo by Pockyt before you can associate payees with them. Contact your Pockyt Solutions representative to set up Payor entities.

How the Models Compare

API Differences

Both models use the same payout endpoints. The differences are limited to a single parameter (payorNo) and an additional object in responses (payorInfo).

The payorNo Parameter

MoR integrations must include payorNo when registering payees and creating payout accounts. This associates the payee with a specific Payor under the Merchant of Record.

Direct Merchant — Register Payee request:

{
  "merchantNo": "203780",
  "storeNo": "303661",
  "firstName": "Jane",
  "lastName": "Doe",
  "email": "[email protected]"
}

MoR — Register Payee request:

{
  "merchantNo": "203780",
  "storeNo": "303661",
  "payorNo": "P87654321",
  "firstName": "Jane",
  "lastName": "Doe",
  "email": "[email protected]"
}

⚠️

Important: Once a payee is registered with a payorNo, the Payor association cannot be changed. Make sure the correct payorNo is used at registration time.

The payorInfo Response Object

For MoR integrations, query and retrieval responses include a payorInfo object confirming the Payor association:

{
  "payorInfo": {
    "merchantNo": "P87654321",
    "merchantName": "Partner ABC",
    "status": "ACTIVE"
  }
}

Direct Merchant responses do not include this object.

Document Upload (MoR Only)

MoR integrations require payee verification documents to be uploaded via the POST /document/upload endpoint. This endpoint is specific to the MoR flow and is not used by Direct Merchants.

Choosing the Right Model

Use Direct Merchant if:

• Your business manages its own payees and payouts directly
• You don't need to process payouts on behalf of other businesses
• You want the simplest integration path

Use Merchant of Record if:

• You are a platform, PSP, or Financial Institution that provides payment services to other businesses
• You need to manage payees across multiple sub-merchants (Payors)
• Compliance requirements demand clear separation between Payor entities and their payees

What's Next

For the full MoR payout workflow — including payee registration, document upload, account creation, and payout execution — see the Merchant of Record Payout Workflow guide.

📘

API References for MoR-related endpoints:

• Register Payee
• Create Payout Account
• Document Upload
• Execute Payout
• Query Payout

Key Considerations

1. Same Endpoints, Different Context: Direct Merchant and MoR integrations hit the same API endpoints. The only code-level difference is including payorNo in requests and handling payorInfo in responses.

2. Payor Association is Permanent: A payee's payorNo cannot be modified after registration. Plan your Payor structure before onboarding payees.

3. MoR Account Deletion Restrictions: Deleting a payout account under the MoR model is subject to Payor status validation. Accounts tied to a Payor with a DECLINED or SAVED status may have restrictions on deletion.

4. Error Handling: A ret_code of 000100 indicates success on all Pockyt API responses. Handle errors consistently and implement retry logic for transient failures.