Payouts: Manual vs Seller Self Payout
Why payouts matter in Ribbn (talk track)
Ribbn is an end-to-end resale commerce platform—from intake → inventory → webshop/POS → multi-seller commissions → payout. Payouts are where trust is won or lost: sellers want clarity on what sold, what’s still in a return/holding period, what’s approved, and when money arrives.
Use this page to:
- Handle payout objections (“I don’t want to do payouts manually,” “Sellers will constantly ask where their money is,” “We need compliance/security”)
- Qualify the right payout model: Manual payout vs Seller Self Payout
SDR goal: You’re not training operators. You’re qualifying the merchant’s needs and mapping them to the correct Ribbn workflow—then booking the meeting with clear requirements.
Two payout models at a glance
| Topic | Manual Payout (Admin-driven) | Seller Self Payout (Seller-initiated) |
|---|---|---|
| Who initiates the payout? | Merchant sends a bank transfer outside Ribbn, then updates status in Admin | Seller taps Cash Out in the Ribbn App after merchant marks items payout-ready |
| Where does payout “work” happen? | Ribbn Admin + merchant’s online banking | Ribbn Admin (approval step) + Ribbn App (seller cash out) |
| Best for | Stores that want full control and already run payouts in their own banking cadence | Stores that want to reduce manual workload and cut payout questions with in-app transparency |
| Seller experience | Sellers typically ask for updates; merchant must communicate timing | Sellers can see wallet balance + what’s pending vs eligible vs paid |
| Lifecycle safeguard | Don’t pay out until return/holding conditions are satisfied | Same safeguard—merchant only marks items ready after return/holding conditions are satisfied |
| Timing expectation you can share | Depends on merchant’s process | Funds arrive in seller bank account within ~2 business days after cash out |
| Security/compliance statement (limited to documented behavior) | Not explicitly documented here (merchant is transferring funds via their bank) | Seller banking data handled between Tink and Stripe; Ribbn does not store banking info; flow is encrypted and PSD2-compliant |
Never promise payout timing for Manual Payout. For Seller Self Payout, only claim the documented “within two business days” *after the seller completes Cash Out*.
Core narrative (use on calls)
When the prospect says: “Payouts are a headache.”
Use:
- “Ribbn’s payout workflows are designed to keep inventory, sales, return windows, and seller payouts tied to the same lifecycle statuses—so you don’t lose track of what’s actually eligible to pay.”
When the prospect says: “Sellers always ask where their money is.”
Use:
- “With Seller Self Payout, sellers can see their wallet balance in-app and exactly which items are in holding, eligible, or already paid—which reduces back-and-forth.”
When the prospect says: “We need control because of returns/holding periods.”
Use:
- “Ribbn supports a return/holding period status. You only approve items for payout once your policy conditions are met—then payout happens cleanly.”
How Seller Self Payout works (what you should know as an SDR)
What the seller sees (Ribbn App)
- Wallet balance
- Indicators showing items that are:
- sold and in the return/holding period
- eligible for payout
- already paid out
What happens behind the scenes (high level)
- Sale funds are held securely in Ribbn’s Stripe account after the sale.
- When the merchant marks items payout-ready, funds are released simultaneously to:
- the merchant
- the seller
- Seller banking data is handled between Tink and Stripe:
- Ribbn does not store banking information
- flow is encrypted and PSD2-compliant
Seller cash-out options (what to say if asked)
- Connect bank account via Tink using BankID, or
- Manually enter an IBAN
Timing
- After Cash Out, funds arrive in the seller’s bank account within two business days.
Best SDR framing: “Self payout is marketplace-style: you approve eligibility; the seller initiates cash out; the system keeps it transparent.”
Manual Payout (Admin-driven) — what it is and when it fits
What “Manual Payout” means in Ribbn
Manual payout is when:
- The merchant pays the seller via bank transfer outside Ribbn
- Then updates item statuses in Ribbn Admin to keep records accurate
Recommended sold-item workflow (status-based)
Ribbn uses statuses to ensure payout happens only when items are truly eligible:
| Stage | Typical status | Why it matters |
|---|---|---|
| Item sold | Sold – Return period open | Prevents paying before the return/holding window is over |
| Ready to pay seller | Sold – Seller To Be Paid | This is the “payout queue” status |
| Payout completed | Sold – Seller Paid | Keeps reporting and seller records accurate |
Manual payout should only be processed for items in **Sold – Seller To Be Paid** to avoid paying out before return windows end.
Manual payout steps (keep it high-level on calls)
- Filter items in Admin by Sold – Seller To Be Paid (and relevant “To Be Paid Date”).
- Confirm seller payment details (message seller if needed).
- Pay via merchant’s banking platform.
- Update items to Sold – Seller Paid in Ribbn.
Seller Self Payout status progression (talk track)
Use this to explain “how it works” without going too deep into admin training.
| Step | Status / event | Who acts | What it means |
|---|---|---|---|
| 1 | Sold – Return period open | System | Item sold; holding/return period active |
| 2 | Sold – Seller Self Pay | Merchant (Bulk Edit) | Merchant approved item(s) for seller cash out |
| 3 | Email + in-app status card | System | Seller is notified that funds are ready |
| 4 | Cash Out completed | Seller | Seller initiates payout to bank |
Qualification: Which payout model does the prospect need?
Quick decision tree (for SDRs)
- Do they want sellers to self-serve payouts (marketplace-style)?
- If “Yes” → Seller Self Payout
- If “No / we want full control” → likely Manual Payout
- Is payout volume high or are payouts causing support load?
- If “High volume / lots of seller questions” → Seller Self Payout is a strong fit
- Do they require a strict holding/return window before funds can be released?
- Both models support a holding/return period concept via statuses
- Key qualifier: “Who should initiate the payout once eligible—your team or the seller?”
- Do they already have an established payout cadence/process in their banking?
- If “Yes, we do payouts weekly/monthly” → Manual Payout can map cleanly
- If “We don’t want to touch payouts” → Seller Self Payout
You can position this as a workflow choice, not a philosophical debate: “Ribbn supports both—let’s pick the model that matches your operating rhythm and seller expectations.”
Discovery questions (copy/paste for call prep)
Payout operations & volume
- “How often do you pay sellers today—per sale, weekly, monthly?”
- “Roughly how many sellers do you pay out in an average week/month?”
- “Do payouts create support tickets or in-store friction?”
Return/holding policy
- “Do you have a return or exchange window that impacts when you can release seller funds?”
- “Is that policy different for in-store vs online sales?”
Seller expectations & experience
- “Do your sellers expect marketplace-like cash-out, or are they used to scheduled payouts?”
- “How important is it for sellers to see a live balance and eligibility status?”
Systems & trust
- “Do you want payouts handled inside the Ribbn experience, or do you prefer to keep transfers entirely in your bank and just track it in Ribbn?”
Objection handling (first-line talk tracks)
“We don’t want to manage payouts manually.”
Response:
- “That’s exactly what Seller Self Payout is designed for—your team approves which sold items are eligible after the return/holding period, and then sellers cash out themselves in the app.”
“Sellers constantly ask where their money is.”
Response:
- “With self payout, sellers can see pending vs eligible vs paid in the app, which reduces confusion and follow-ups.”
“Is seller banking data stored in Ribbn?”
Response (stay within documented behavior):
- “Ribbn doesn’t store seller banking information. Banking data is handled securely between Tink and Stripe, and the flow is encrypted and PSD2-compliant.”
“We’re worried about paying out before returns are settled.”
Response:
- “Ribbn’s workflow uses a return/holding period status. You only move items to payout-ready once your return policy conditions are satisfied.”
Pricing/packaging guardrails (what you can and can’t say)
- You can say: Ribbn supports two payout workflows (manual + self payout) and they’re driven by lifecycle statuses.
- You should not say: exact plan entitlements, transaction fees, or add-on pricing unless you have the current pricing sheet for the prospect’s market.
- You can do: confirm whether payouts are a must-have requirement and flag it clearly for the AE/demo.
Don’t make tax/VAT/compliance promises beyond the documented statements about bank data handling (Tink + Stripe, Ribbn doesn’t store banking info, PSD2-compliant).
What to capture in the meeting handoff (SDR → AE)
Use this checklist in your notes:
- Current payout method (manual transfers? platform payouts?)
- Payout cadence (daily/weekly/monthly)
- Return/holding policy (and whether it differs online vs in-store)
- Seller experience expectations (self-serve wallet vs scheduled payout)
- Estimated seller count + payout volume
- Any security/compliance concerns (especially around bank data handling)
Quick glossary (for SDR clarity)
- Return/Holding period: Time after a sale where funds shouldn’t be released due to return/exchange policy.
- Wallet balance (seller): What the seller can see in the Ribbn App for self payout.
- Statuses: Lifecycle labels in Ribbn Admin that control what happens next and keep payout records consistent.
- Bulk Edit: Admin action used to move multiple items to payout-ready statuses efficiently.