Percentage vs Flat Split Configuration on Paystack

A percentage split divides the transaction amount by ratio. You set percentage_charge on the subaccount to the percentage the subaccount should receive. Your main account gets whatever is left after the subaccount's share and the Paystack processing fee (depending on bearer configuration).

// Create a subaccount with an 80% share (platform keeps 20%)
var response = await fetch('https://api.paystack.co/subaccount', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer ' + process.env.PAYSTACK_SECRET_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    business_name: 'Mama Njeri Kitchen',
    settlement_bank: '058',
    account_number: '0123456789',
    percentage_charge: 80,
  }),
});

With this subaccount, every transaction that references it will give 80% to the subaccount and 20% to your platform. The split adjusts automatically with transaction size:

• Customer pays 2,000 NGN: subaccount gets 1,600, platform gets 400
• Customer pays 10,000 NGN: subaccount gets 8,000, platform gets 2,000
• Customer pays 50,000 NGN: subaccount gets 40,000, platform gets 10,000

This proportional scaling is why percentage splits are the default choice for most marketplaces. Your commission grows as your vendors sell more expensive items. You do not need to adjust anything as the price range on your platform expands.

The percentage is always from the vendor's perspective. If you set percentage_charge: 80, the vendor gets 80% and you keep 20%. If you want to express it as "the platform takes 15%", set the subaccount's percentage_charge to 85.

A flat split takes a fixed amount from each transaction for your main account. You set it by passing transaction_charge (in the smallest currency unit) when initializing the transaction. The subaccount gets the transaction amount minus your flat charge.

// Initialize a transaction with a flat charge of 500 NGN
var response = await fetch('https://api.paystack.co/transaction/initialize', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer ' + process.env.PAYSTACK_SECRET_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    email: 'buyer@example.com',
    amount: 1000000, // 10,000 NGN in kobo
    subaccount: 'ACCT_abc123xyz',
    transaction_charge: 50000, // Platform keeps 500 NGN (50,000 kobo)
    bearer: 'account',
  }),
});

With a flat charge of 500 NGN, your commission stays the same regardless of order value:

• Customer pays 2,000 NGN: platform gets 500, subaccount gets 1,500
• Customer pays 10,000 NGN: platform gets 500, subaccount gets 9,500
• Customer pays 50,000 NGN: platform gets 500, subaccount gets 49,500

Notice how the vendor's take-home percentage increases with order value. At 2,000 NGN, the vendor keeps 75%. At 50,000 NGN, the vendor keeps 99%. This is the opposite of percentage splits, where the ratio stays constant.

Flat splits make vendors happy on expensive items because your fee feels small relative to the price. But they make your unit economics harder on cheap items because the same 500 NGN fee represents 25% of a 2,000 NGN order.

Let us compare both models across a realistic range of transaction sizes. This is the analysis you should do before choosing your split model.

Scenario: Percentage split at 85/15 (vendor gets 85%, platform keeps 15%)

Order Value	Vendor Gets	Platform Gets	Platform %
1,000 NGN	850	150	15%
5,000 NGN	4,250	750	15%
10,000 NGN	8,500	1,500	15%
50,000 NGN	42,500	7,500	15%
200,000 NGN	170,000	30,000	15%

Scenario: Flat split at 750 NGN per transaction

Order Value	Vendor Gets	Platform Gets	Platform %
1,000 NGN	250	750	75%
5,000 NGN	4,250	750	15%
10,000 NGN	9,250	750	7.5%
50,000 NGN	49,250	750	1.5%
200,000 NGN	199,250	750	0.375%

The flat model produces identical revenue at the 5,000 NGN price point, but diverges sharply above and below it. At 1,000 NGN, the flat charge takes 75% of the transaction, which no vendor would accept. At 200,000 NGN, the platform earns less than half a percent, which might not cover operating costs.

These numbers are before Paystack processing fees. The fee further reduces whichever party is the bearer. Factor the fee into your analysis using realistic estimates for your market and transaction channel (card vs mobile money vs bank transfer).

The takeaway: percentage works when your value proposition scales with transaction size. Flat works when your value proposition is constant per transaction, and your transaction sizes fall in a narrow range where the flat fee feels fair to both parties.

The percentage_charge on a subaccount is the default. You can override it on any individual transaction by passing transaction_charge when initializing. This gives you flexibility to use percentage as the baseline but switch to flat for specific cases.

// Override the default percentage with a flat charge for this transaction
async function initializeWithOverride(order, seller) {
  var chargeParams = {
    email: order.buyerEmail,
    amount: order.totalInKobo,
    subaccount: seller.paystackSubaccountCode,
    bearer: 'account',
    reference: 'order_' + order.id + '_' + Date.now(),
  };

  // Apply promotional pricing: flat 200 NGN fee for VIP sellers
  if (seller.tier === 'vip') {
    chargeParams.transaction_charge = 20000; // 200 NGN in kobo
  }
  // Otherwise, the subaccount's default percentage_charge applies

  var response = await fetch('https://api.paystack.co/transaction/initialize', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer ' + process.env.PAYSTACK_SECRET_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(chargeParams),
  });

  return await response.json();
}

Common reasons to override per transaction:

• Promotional pricing: Offer new vendors a lower commission rate for their first month. Override with a smaller flat charge or create a separate subaccount with a higher percentage_charge.
• High-value order caps: Your standard 15% feels excessive on a 500,000 NGN order. Cap your commission at 20,000 NGN by switching to a flat charge on orders above a threshold.
• Category-specific pricing: Electronics (low margin for the vendor) get a 10% platform fee, while services (high margin) get 20%. Calculate the right parameter per transaction based on the product category.
• Negotiated rates: Enterprise vendors negotiate custom commission rates. Store their rate in your database and apply it per transaction.

When you pass transaction_charge, it replaces the percentage split with a flat split for that transaction only. The subaccount's default percentage_charge is not permanently changed.

The most common hybrid is "percentage with a minimum." You want 15% of every transaction, but never less than 200 NGN. Paystack does not support this with a single parameter. You build it on your server.

// Hybrid model: 15% commission with a 200 NGN floor
function calculateSplitParams(orderAmountKobo) {
  var percentageCommission = Math.floor(orderAmountKobo * 0.15);
  var minimumCommission = 20000; // 200 NGN in kobo

  if (percentageCommission >= minimumCommission) {
    // 15% exceeds the minimum, use percentage split (let subaccount default handle it)
    return { useDefault: true };
  } else {
    // 15% is below the minimum, override with flat charge
    return {
      useDefault: false,
      transaction_charge: minimumCommission,
    };
  }
}

// Use it during transaction initialization
async function initializeHybridSplit(order, seller) {
  var splitParams = calculateSplitParams(order.totalInKobo);

  var body = {
    email: order.buyerEmail,
    amount: order.totalInKobo,
    subaccount: seller.paystackSubaccountCode,
    bearer: 'account',
    reference: 'order_' + order.id + '_' + Date.now(),
  };

  if (!splitParams.useDefault) {
    body.transaction_charge = splitParams.transaction_charge;
  }

  var response = await fetch('https://api.paystack.co/transaction/initialize', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer ' + process.env.PAYSTACK_SECRET_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(body),
  });

  return await response.json();
}

Other hybrid patterns:

Percentage with a cap. You take 15% but never more than 5,000 NGN. Same logic, reversed: if the percentage exceeds the cap, override with a flat charge of 5,000 NGN.

Tiered percentage. Different commission rates at different price brackets. Orders under 5,000 NGN get charged 20%, orders between 5,000 and 50,000 get 15%, orders above 50,000 get 10%. Calculate the appropriate transaction_charge (flat amount) on your server and pass it per transaction.

Flat plus percentage. A fixed platform fee of 100 NGN plus 10% of the order. Calculate the total commission on your server and pass it as transaction_charge.

All of these hybrids require server-side logic. The trade-off is complexity: your code now makes a business decision on every transaction. But the flexibility lets you build pricing models that match your market rather than forcing your business into Paystack's two built-in options.

Here is a decision framework based on what your platform actually does.

Use percentage when:

• Your platform's value to the vendor scales with transaction size (bigger orders require more logistics, support, or marketing from you)
• Your transaction sizes vary widely (1,000 to 200,000 NGN on the same platform)
• You want a simple model that requires no per-transaction logic on your server
• Your vendors are accustomed to revenue-share models (common in e-commerce, food delivery, freelancing)

Use flat when:

• Your platform provides the same service regardless of transaction size (listing a 2,000 NGN item costs you the same as listing a 200,000 NGN item)
• Your transaction sizes cluster in a narrow range (most orders are between 3,000 and 8,000 NGN)
• You charge a service fee (booking fee, processing fee, listing fee) rather than taking a revenue share
• Your vendors sell high-value items and would resist a percentage commission on large orders

Use a hybrid when:

• You need a percentage model but cannot afford to earn below a minimum per transaction
• You want percentage for most orders but a cap on expensive items to keep vendors happy
• Different product categories or vendor tiers need different pricing

Whatever you choose, model it with your actual transaction data. Pull your last 1,000 orders, apply both percentage and flat models, and see which one produces sustainable revenue across your real transaction distribution. Theoretical analysis with made-up numbers misses the skew in your actual data.

For the broader context of how split configuration fits into marketplace architecture, see the Paystack split payments and marketplaces complete guide.

The split configuration is not just a technical decision. It is a business model decision that affects vendor acquisition, vendor retention, and your unit economics. Getting it right requires understanding both the API mechanics and the market dynamics.

The McTaba bootcamp teaches payment integration alongside business thinking. You do not just learn to call the API. You learn to design payment flows that sustain a real business.

Create a free McTaba account