Instant delivery

Lifetime updates

1 domain license

Addonv6.3.1

P2P Trading for Bicrypto

Name: P2P Trading for Bicrypto
Brand: MashDiv
SKU: p2p
Price: 219.00 USD
Availability: InStock

Your users trade cash for crypto with each other while you hold the escrow, take a fee and rule disputes.

4.70111 sales

$219$249Save 12%

You'll also need Bicrypto

On its own, P2P Trading for Bicrypto won't work — it only runs if you already own Bicrypto. Open the Requirements tab to see exactly what you need and add it to your order.

See it working Live demo Documentation View on CodeCanyon

Escrow is a real wallet hold, taken before a buyer is asked to send money
One settlement authority pays a trade out once, whichever door closes it
126 curated payment rails across 42 countries, created in a single pass
Eight dispute reasons and four rulings — buyer, seller, split or cancel
Private trade chat with image evidence, kept on the trade's own timeline
A cron expires unpaid trades and hands the capacity back to the offer
Stale payments auto-dispute after 24 hours, so a buyer is never stranded
An approval queue holds every new offer until you put it on the board
One escrow fee, 0-5%, out of the buyer's proceeds — no maker or taker fee
Optional second factor on the seller, and a fresh code at every release
Twelve permission keys, so support reads a dispute without ruling on it
Reputation from completed trades, completion rate and three review scores

Inside P2P Trading

You hold the crypto. They settle the cash between themselves.

A maker posts an offer, a taker opens a trade against it, and the platform locks the seller's crypto until the seller says the money arrived. The fiat leg never touches your infrastructure — which is exactly why this is a marketplace you can actually run.

In detail

P2P Trading gives your users a marketplace where they buy and sell crypto directly from each other, and gives you the only role that matters: you hold the crypto in escrow, you arbitrate what goes wrong, and you take a percentage of every completed trade. The cash leg happens bank to bank between the two people, so there is no payment provider to onboard, no chargeback exposure and no fiat rail for you to operate.

How it works

A maker publishes an offer — sell 500 USDT at 1.02 EUR, bank transfer only, thirty minutes to pay — and a SELL offer's whole advertised total leaves their spendable balance for hold the moment it is published. A taker opens a trade against it, the buyer pays the seller outside the platform by whatever method the offer names, the seller presses release, and the escrow settles to the buyer net of your fee. One settlement authority moves every payout behind a single guard, so a trade pays out at most once whichever of the six doors closes it. If the buyer never pays, the cron expires the trade and the offer gets its capacity back.

The configurable surface

Surface	What you set
Fees	one escrow fee, 0–5%, taken out of the buyer's proceeds
Limits	a platform minimum and maximum, plus per-currency dust floors
Windows	the default payment window, and auto-cancel on or off
Offers	an approval queue, or auto-approve straight to the board
Release	require a second factor on the seller, and a code at release
Rails	126 curated payment methods across 42 countries

What operators control

Seventeen settings across four tabs, and twelve permission keys — so a support account can read a dispute without being able to rule on it. Offers can be approved, rejected, flagged, paused or disabled; trades can be cancelled or force-resolved; disputes carry eight reasons, three priorities and four rulings. Every admin action is written to an activity log, and trades, offers, disputes, payment methods and rails each get their own screen.

P2P is an addon: it needs a working Bicrypto core install, a reachable Redis and the cron process running. It does not move fiat, does not verify that a payment arrived, and does not enforce an offer's stated country restrictions — the seller's judgement is the only confirmation and a dispute is the only appeal. Offers priced in ECO currencies additionally require the Ecosystem addon.

Escrow is a wallet hold, taken before anyone is asked to pay

Publishing a SELL offer moves its whole advertised total out of the maker's spendable balance and into hold, in the same transaction that writes the offer row. So every row on your board is already collateralised before a stranger can act on it. One settlement authority moves that money, guarded by the trade's own escrow state, so a trade pays out at most once no matter which of the six doors closes it.

A BUY offer holds nothing at publish — there the taker is the seller and their funds are held when the trade opens. Redis must be reachable: initiation, release and cancellation take a distributed lock and answer 503 rather than risk a double payout.

When they disagree, the escrow freezes and you rule

Either party can dispute a trade whose payment has been declared but not released, choosing from eight reasons, and the escrow simply stops. You get the timeline, the payment-details snapshot taken when the trade opened, the attached evidence and the chat, then pick one of four rulings: buyer wins, seller wins, split by an explicit share, or cancelled. The ruling is what moves the money — the same settlement authority, the same one-payout guard.

A completed trade cannot be reopened, deliberately: a second payout would be drawn from whatever else the seller was holding, in practice another offer's escrow. Post-completion complaints are a support matter, not a P2P one.

A marketplace is only as real as its payment rails

An empty payment-method list means nobody can publish an offer, so P2P ships a curated catalogue of 126 real rails across 42 countries plus a euro-area bundle — Opay and PalmPay for Nigeria, PIX for Brazil, UPI for India, SEPA for the euro area. Pick a country, tick the rails you want and create them in one pass. The market filter groups on the rail rather than on each trader's own record, so one PayPal appears however many makers accept it.

A country nobody has curated falls back to five generic rails, and the setup screen says so rather than passing them off as local knowledge. The setup console is permission-gated and no role holds the permission at install — grant it before handing the screen over.

A stranger arrives, and something has to say who to trade with

The board opens on a shelf of suggested counterparties — up to twelve cards, each labelled best, cheapest, safest or also available. Every card names the measured figure it was chosen on and carries its own caution on the same card, so the reason to pick somebody and the reason to hesitate arrive together rather than one of them living behind a click. Underneath sit the numbers those labels come from: completed trades, completion rate, average release time in seconds, and reviews stored as three separate 0–100 dimensions for communication, speed and trust.

A review can only be left on a completed trade, one per trade per reviewer, so a score cannot be run up without trading. An account with no record is labelled a new trader rather than given a flattering default — which loses that trader their first trade and is still the right call, because the alternative is a marketplace where five stars means nothing. Reputation recomputes hourly.

payment rails, 42 countries: 126
dispute reasons: 8
arbitration outcomes: 4
admin permission keys: 12

Everything included

135 capabilities, in 11 areas

Every item below exists in the source you receive. Nothing here is a roadmap.

The marketplace board

What a visitor sees before they have an account.

One market page with three views: suggested counterparties, all offers, and traders
Filters on side, asset, amount, fiat currency, payment rail and country
Five sort orders: best match, price, completed trades, release speed, newest
Guided sentence or classic filter row, remembered per browser
Suggested-counterparty shelf of 1–12 cards, labelled best, cheapest, safest or also available
Every suggestion's reason drawn from a measured figure, with its cautions on the same card
Traders view ranking people rather than offers, by completed trades and release speed
Visitor country and currency detection, guarded so it can never empty the board
Offer permalink any shared link opens, carrying the maker's own record
Pre-publish forecast: where a price lands, how many traders qualify, how long comparable offers waited
Landing page with market stats, top assets, featured offers and top traders
Customer learn pages on escrow, timers, trust and disputes
Guest browsing of the board, switchable

Offers and the book

What a maker publishes, and every rule that decides whether it reaches the board.

BUY and SELL offers, with the board's side named for the viewer rather than the maker
Fixed price, or a margin off the market bounded to ±50% at creation
FIAT, SPOT and ECO wallet types per offer
Eight offer statuses: draft, pending approval, active, paused, completed, cancelled, rejected, expired
Offer total, with per-trade minimum and maximum quoted in the pricing currency
Per-offer payment window in minutes, or zero to never auto-cancel
Written terms of trade required to publish, plus optional notes
Public or private visibility — private is excluded from every listing
Taker requirements: completed trades, success rate, account age, verified email, prior counterparty, KYC
Drafts that hold no escrow at all
One-page composer with a live preview of the card being published
My offers screen: escrow held, trades opened, and the gates behind an offer nobody takes
Edit refused while a trade against the offer is live
Pause, resume and delete, each with its own collateral consequence
Automatic expiry after 30 days untouched with nothing left to sell

Payment methods and rails

An empty method list means nobody can publish, so this is the part that decides launch day.

A shared rail — the name and the fields it needs — separate from each trader's own account details
Country Setup console: pick a country, tick the rails, create them in one pass
126 curated payment methods across 42 countries, plus a euro-area SEPA bundle
Five generic rails as the stated fallback for a country nobody has curated
Fifteen catalogue rails shipping with their field shapes already defined
Payment Rails screen: fields, filter listing, availability and rank
Name matching that treats PayPal, Paypal and pay-pal as one rail
"Did you mean" suggestions when a trader names a rail close to an existing one
Trader-defined rails, up to 12 each, promoted into the public filter at two distinct makers
Global methods any maker can attach, plus up to 20 personal methods per trader
Up to 20 labelled detail fields per method, snapshotted onto every trade
Availability switch that retires a rail without touching anyone's saved details
Deletion refused while a method sits on a live offer or an open trade
One-time repair script that merges duplicate spellings and infers field shapes

The trade room

The screen both parties sit on while the money is in the air.

Six trade statuses: pending, payment sent, completed, cancelled, disputed, expired
Payment-window countdown from the one definition the cron, the API and the UI share
Buyer confirms payment with an optional reference and receipt image
Seller release, idempotent by a Redis result cache and by the escrow guard
Buyer-only cancellation while pending, with a reason of at least 10 characters
Private trade chat delivered over a WebSocket, not polled
Image attachments up to 5 MB, re-encoded and stripped of EXIF metadata
Attachments readable only by the buyer and the seller of that trade
Payment-details snapshot taken as the trade opens, immune to any later edit
Event timeline appended on every status change
Counterparty record on the trade: completed trades, completion rate, new-trader flag
Review of the counterparty once the trade completes
My trades screen: live trades first, sorted by who is holding them up, history beneath
Spendable-balance check that caps the amount before a sell-side trade
One active trade per offer per taker

Escrow and settlement

The guarantee the whole product rests on: a trade pays out at most once.

A SELL offer escrows its whole advertised total the moment it is published
A BUY offer escrows the taker's funds when the trade opens
Four escrow states per trade: none, held, released, refunded
One settlement authority behind all six doors that can end a trade
Four settlement outcomes: release to buyer, refund to seller, return to offer, split
Escrow attributed per offer and per trade, so every hold is reconcilable
Offer capacity restored on cancellation, capped at what is genuinely still held
Amounts clamped to the wallet's real held balance rather than throwing
Distributed locks on initiation, confirm, release and cancel
One wallet idempotency namespace per trade, shared by every door
Six wallet operation types, so escrow can be reconciled from SQL
Ecosystem chain-ledger sync on settlement for ECO wallets

Disputes and arbitration

What happens when the two of them disagree about the cash.

Either party can dispute a trade whose payment has been declared but not released
Eight dispute reasons
A description of 20–1,000 characters, required
Priority assigned automatically at filing: high, medium or low
Three dispute statuses: pending, in progress, resolved
Automatic dispute filed for the buyer after 24 hours in payment-sent
Escrow freezes on filing and moves only on the ruling
Four rulings: buyer wins, seller wins, split, cancelled
Split by percentage or by absolute share, defaulting to an even 50/50
Settlement projection drawn beside the button before it is pressed
A mandatory written finding, recorded on the trade and on the dispute
Attestation checkbox, and a commit button that names the amount and the recipient
Evidence gallery an operator attaches to the case
Dispute thread separate from the trade chat, plus internal notes users never see
Guards: no ruling on your own trade, none without an outcome, none twice

Reputation and reviews

Completed trades, finished trades and completion rate per trader
Average release time in seconds, measured on the selling side only
Reviews stored as three 0–100 dimensions: communication, speed and trust
One review per trade per reviewer, on completed trades only
A new-trader flag instead of a flattering default for an unproven account
Repeat-counterparty flag for people the viewer has already traded with
Hourly reputation recompute, with 10, 50 and 100-trade milestone notifications
Disputes filed and disputes filed against, per party, on the admin case screens

The admin desk

Fourteen screens, arranged as a work queue rather than a dashboard.

Desk dashboard built as two aged queues: disputes against 24 hours, offer approvals against 72
Trade pipeline split by which party is being waited on
Per-currency volume, revenue and frozen escrow — never summed across currencies
Seven-day throughput chart bucketed in UTC on both sides
Offer approval queue with approve, reject, pause, activate, disable, flag and note
Offer case screen drawing only the doors the offer's status actually permits
Full-screen trade case desk with a pinned ribbon, four progress steps and a posture badge
Four intervention doors on a trade, each naming what it does to the money
Admin broadcast into the trade chat, and internal notes users never see
Trade, offer, dispute and payment-method lists, each filtered server-side
Admin offer edit form covering every field the maker's own form has
Manual trigger for the timeout handler
Activity log with category, severity and full-text search across the whole table
Audit rows written inside the same transaction as the escrow they describe

Fees and revenue

One escrow fee, 0–5%, taken out of the crypto delivered to the buyer
The rate locked in at trade initiation and charged at settlement
Fee charged only on value delivered to the buyer, never on a refund
A fee floor that can never approach the value of a small trade
Super Admin sellers exempt from the fee entirely
A commission row per collected fee, joined to its trade for the currency
A platform profit ledger row per fee, carrying the wallet type and chain
Platform minimum and maximum trade amounts, enforced at publish and at trade start
Per-currency dust floors that override the dollar minimum

Security and access control

Twelve permission keys gating every admin screen and every door
Require 2FA to sell — the seller must hold a second factor before a trade can start
Require a 2FA code at release, with its own token purpose and key namespace
Recovery codes accepted at the release challenge
Both 2FA switches Super-Admin-only, and chained so the challenge cannot be armed alone
An endpoint that tells a seller exactly which policy they face right now
Two KYC feature gates: making an offer, and taking one
A per-offer KYC requirement the maker sets on takers
Rate limits on publishing, taking a trade, chat, disputes and search
Trade-chat attachments stored outside both web roots, at a path you set
Extension licence gate in front of every P2P route, public ones included

Settings and operations

Seventeen settings across four tabs: trading, fees and limits, platform, UI
Auto-approve offers, or hold every one of them for a human
Auto-cancel unpaid trades, with a platform default payment window
Two cron jobs: a one-minute timeout sweep and an hourly reputation pass
Trade, offer and reputation notifications over in-app, email and push
Dispute fan-out to every Admin and Super Admin
Offer approval and rejection notices carrying the reason you wrote
Section, maintenance and new-offer switches that close the customer UI
Eleven tables, all soft-deleting

Licence: Extension licence for P2P Trading — full source, activated on your install
Requires: A working Bicrypto core install. P2P adds routes, screens and tables to the same tree — there is no separate P2P deployment.
Also needs: Redis reachable, and the cron process running. Both are already part of a standard core install.
Processes: None of its own — it runs inside the core backend and the core cron worker
Data: 11 tables added to the core database, all soft-deleting
Admin surface: 14 admin screens
Customer surface: 11 customer screens
Endpoints: 82 — 48 customer, 34 admin, one of them a WebSocket
Access control: 12 permission keys, none of them held by a role at install
Settings: 17, across four tabs
Background work: 2 cron jobs: a one-minute timeout sweep and an hourly reputation pass
Payment rails: 126 curated methods across 42 countries, plus a euro-area SEPA bundle
Fee: One escrow fee, 0–5%, shipped at 0.2% — no maker, taker or dispute fee
Wallets: FIAT, SPOT and ECO offers
Works with: The MLM addon, if installed, pays referral rewards on completed P2P trades. It is not required.
It does not move fiat: No bank integration, no provider confirmation, nothing that verifies a payment arrived. The seller's judgement is the confirmation and a dispute is the only appeal.
A completed trade is terminal: There is no reversal door and there must not be — a second payout would be drawn from whatever else the seller was holding, in practice another offer's escrow.
Country restrictions are stated, not enforced: An offer can name restricted countries and takers are shown them, but nothing blocks a taker on that basis: the platform has no trustworthy per-user country to check against.
The market API is public: The board, the offer permalink and eleven other read endpoints answer anonymous requests. The three kill switches close the customer UI, not the API, and there is no signed-in-only mode — that is a reverse-proxy rule, not a setting.
Every deadline is cron work: Payment windows, escrow return, the 24-hour stale-payment net and offer expiry all run in the one-minute job. With the cron process down an unpaid trade holds the seller's funds indefinitely, and nothing in the UI says so.
ECO offers need the Ecosystem addon: FIAT and SPOT offers run on the core alone. An ECO offer has no token list to validate against and no wallet to settle into without it — a choice you make later, not a prerequisite for buying.
No reputation screen, and no retention job: There is no admin door that edits a score or removes a review, and nothing prunes the activity log, the commissions table or the attachment stores. Both file stores belong in the same backup set as the database.