The bearer parameter on a Paystack split transaction controls who absorbs the processing fee. Set bearer to "account" and your main account pays the fee. Set it to "subaccount" and the vendor pays. Set it to "all" and the customer pays the fee on top of the product price. The default is "account" for most configurations. Getting this wrong is one of the most expensive mistakes in marketplace development.
Every Paystack transaction has a processing fee. On a regular (non-split) transaction, the fee comes out of your settlement. Simple. But on a split payment, the money is going to multiple parties, and the fee has to come from somewhere specific. The bearer parameter decides where.
This sounds like a minor configuration detail. It is not. The bearer setting directly affects the take-home amount for every party on every transaction. On a marketplace processing thousands of transactions per month, the wrong bearer configuration silently erodes margins in a way that only shows up when you do the accounting.
Consider a marketplace with a 15% commission. If the processing fee is around 1.5% of the transaction, and the platform bears the fee, the actual margin is closer to 13.5%. That is a 10% reduction in your effective commission. At scale, that is the difference between a profitable marketplace and one that cannot cover its operating costs.
The three bearer options represent three different business philosophies about who should absorb the cost of payment processing. There is no universally correct answer. The right choice depends on your market position, vendor relationships, and unit economics.
When bearer is set to account, the Paystack processing fee is deducted from your main account's share of the split. The subaccount receives their full calculated portion. This is the default for most Paystack configurations.
// Platform bears the processing fee
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_vendor_123',
bearer: 'account',
}),
});
With an 80/20 split on a 10,000 NGN transaction (bearer: account):
When to use account bearer:
The risk: on small transactions, the fee can consume a large portion of your commission. If your 20% commission on a 500 NGN transaction is 100 NGN, and the Paystack fee on that transaction is a significant fraction of 100 NGN, your actual take-home is very thin.
Get weekly developer tips
Join 25,000+ developers. Practical guides, job tips, and new content — straight to your inbox.
No spam. Unsubscribe anytime.
When bearer is set to subaccount, the Paystack processing fee is deducted from the subaccount's share. Your main account receives its full calculated commission.
// Vendor bears the processing fee
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_vendor_123',
bearer: 'subaccount',
}),
});
With an 80/20 split on a 10,000 NGN transaction (bearer: subaccount):
When to use subaccount bearer:
The risk: vendors see a lower payout than the percentage you advertise. If you tell a vendor "you get 80% of every sale" but the processing fee comes out of their share, their actual take-home is less than 80%. This creates a trust gap unless you communicate it clearly during onboarding. Some vendors will compare their actual settlement to the promised percentage and feel shortchanged.
When bearer is set to all, Paystack calculates the processing fee and adds it to the transaction amount. The customer pays the product price plus the fee. Neither your main account nor the subaccount is reduced by the fee.
// Customer bears the processing fee
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_vendor_123',
bearer: 'all',
}),
});
With an 80/20 split on a 10,000 NGN product (bearer: all):
When to use all bearer:
Risks and restrictions:
Here is the same 10,000 NGN transaction with an 80/20 split under each bearer option. The fee is represented as F since the actual amount depends on the payment channel and Paystack's current pricing.
| Bearer | Customer Pays | Vendor Gets | Platform Gets | Who Loses F |
|---|---|---|---|---|
| account | 10,000 | 8,000 | 2,000 - F | Platform |
| subaccount | 10,000 | 8,000 - F | 2,000 | Vendor |
| all | 10,000 + F | 8,000 | 2,000 | Customer |
The total money in the system is always: product price + Paystack fee. The bearer parameter just determines which party's pocket the fee comes from.
At small transaction amounts, the fee is a larger percentage of the total, so the bearer decision has a bigger impact. At large transaction amounts, the fee is a smaller percentage (especially for card payments where there is often a cap), so the bearer decision matters less.
Run this analysis at your smallest common transaction size. That is where the pain is. If your minimum order is 500 NGN, calculate all three scenarios at 500 NGN and see which one leaves each party with an acceptable amount.
You are not locked into one bearer option for all transactions. You can set it per transaction when initializing, and per split group for multi-split transactions.
// Dynamic bearer based on transaction context
async function initializeWithDynamicBearer(order, seller) {
var bearer = 'account'; // default: platform bears the fee
// For high-value orders, let the subaccount bear the fee
// because the platform's percentage commission is already large
if (order.totalInKobo > 5000000) { // orders over 50,000 NGN
bearer = 'subaccount';
}
// For ticket purchases, let the customer bear the fee
// (industry norm for event ticketing)
if (order.type === 'ticket') {
bearer = 'all';
}
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: order.buyerEmail,
amount: order.totalInKobo,
subaccount: seller.paystackSubaccountCode,
bearer: bearer,
reference: 'order_' + order.id + '_' + Date.now(),
}),
});
return await response.json();
}
For multi-split groups, you set the bearer using bearer_type when creating the split group:
// Multi-split with specific bearer configuration
var splitResponse = await fetch('https://api.paystack.co/split', {
method: 'POST',
headers: {
Authorization: 'Bearer ' + process.env.PAYSTACK_SECRET_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({
name: 'Order Split',
type: 'percentage',
currency: 'NGN',
subaccounts: [
{ subaccount: 'ACCT_restaurant_123', share: 65 },
{ subaccount: 'ACCT_rider_456', share: 15 },
],
bearer_type: 'account', // Platform bears the fee
bearer_subaccount: '',
}),
});
If you set bearer_type to subaccount on a multi-split group, you must also specify bearer_subaccount to indicate which subaccount absorbs the fee. The fee is not split among all subaccounts; one specific subaccount bears the entire fee.
The bearer decision is an economics question, not a technical one. Here is how to analyze it for your specific marketplace.
Step 1: Know your transaction distribution. What are your actual order values? Not the average. The distribution. If 60% of your orders are under 2,000 NGN and 10% are over 20,000 NGN, the sub-2,000 cohort dominates your fee calculation.
Step 2: Model each bearer option at your smallest common order size. If most orders are 1,000 NGN and your commission is 15%, your gross take is 150 NGN per order. If the processing fee at 1,000 NGN eats a large chunk of that 150 NGN, bearer: account might leave you with an unsustainably thin margin.
Step 3: Consider your vendor acquisition strategy. Can you attract vendors with a "subaccount bears the fee" policy? If you are the dominant platform with no competition, maybe. If vendors have alternatives, they will go to the platform that offers cleaner payouts. Bearer: account is often the cost of being competitive in early-stage marketplaces.
Step 4: Consider customer price sensitivity. If your customers are price-sensitive (common in most African markets), adding a surcharge with bearer: all might reduce conversion rates. Test it. Some platforms find the conversion drop offsets the margin gained from not bearing the fee.
Step 5: Run the numbers over a month. Take your transaction history, apply each bearer model, and calculate total platform revenue, total vendor payouts, and the fee cost. The option that produces sustainable margins while keeping vendors and customers happy is the right one.
For a broader discussion of commission strategies including percentage, flat, tiered, and hybrid models, see commission models on Paystack splits.
KES 2,999
The definitive guide to building payment systems with Paystack — from your first transaction to production-grade payment infrastructure across Africa. 9 modules, 47 lessons. Free preview available.
Start Paystack Course