.
👤PARTIES
A: seller
B: buyer
C: seller A’s trusted person
D: buyer B’s trusted person
Platform: neutral arbiter
🎯 System OBJECTIVE:
The main goal of the system is to:
✅secure exchanges;
✅protect buyers and sellers;
✅prevent scams;
The payment is temporarily held by the platform until the final validation of the transaction following the physical exchange.
==============================================================================
1️⃣– AD POSTING and transaction area display
The author publishes an ad based on the category:
“Offer_item”: the author owns an item and wishes to sell it.
“Seek_item”: the author wishes to buy an item and has the funds available.
A marked area automatically appears in the ad containing respectively:
a “Request & Pay💳” button allows a buyer to make a request by making the secure payment.
a “Make an offer ➡️” button allows a seller to make an offer to the buyer, who can then make the request following the seller’s offer.
2️⃣ – STARTING THE TRANSACTION – Transaction request by the buyer
The secure transaction starts when the transfer is made by the buyer.
It is considered in progress once the seller has accepted the buyer’s request.
Conditions before starting a transaction
– The platform automatically verifies several conditions: the user must be logged in;
– the seller cannot buy their own ad;
– an ad already in a transaction process cannot receive a new request or offer;
– a completed ad is no longer available.
💬Before starting a transaction, i.e., making the transfer, the buyer is advised to contact the seller beforehand to agree on the date and location of the physical exchange.
Then the buyer: chooses a physical meeting date from the presented calendar📅 (The physical transaction date must be within an authorized window of maximum 4 days).
Next: sends a transaction request – immediately makes the secure payment💳.
The payment is then temporarily locked🔐by the platform (not immediately transferred to the seller);
3️⃣ – RESPONSE TO THE TRANSACTION REQUEST
Once the payment is held:
both the seller and the buyer receive a notification email;
In the “My Requests” page within the transaction folder of the user area:
The seller can: accept or refuse the request.
If the seller refuses ❌:
the transaction is canceled; the payment is automatically refunded to the buyer.
(The buyer can also cancel the request. If they do, the payment will be directly refunded to them.)
If the seller accepts ✅:
the transaction status changes to: “pending_validation”. (-> Ad marked as transaction in progress🔄)
Both parties then receive their secure PDF documents automatically generated by the platform:
- 📄The transaction contract: containing the transaction number and other transaction information (The transaction contract is automatically concluded when the buyer makes the transfer while sending the request and the seller accepts it.)
- 📄The transaction slip: containing security elements used to secure the physical exchange and validate the transaction.
Users can track all their operations on the “My Transactions” page located in the transaction folder of their respective user area.
4️⃣ – PHYSICAL MEETING between buyer and seller or trusted persons – SIMULTANEOUS EXCHANGE🚨 ITEM for CODE
During the physical meeting:
👤The buyer has: 📄the transaction slip featuring the validation codes (the full SCS Code as well as the full QR Code) allowing for the final validation of the transaction, to be handed to the seller.
👤The seller has: 📄the transaction slip featuring certain secret positions of the SCS Code and a QR Code snippet (This allows them to verify that the information provided is authentic), and 📦the item to be handed to the buyer.
N.B.⚠️The exchange of the slip by the buyer for the item by the seller is done SIMULTANEOUSLY❗by both parties. (Both parties are required to ensure the SIMULTANEOUS nature of the physical exchange, and ONECLICK Services cannot be held responsible for any leak by either party due to this measure not being respected.)
5️⃣ – FINAL TRANSACTION VALIDATION
After the physical exchange, the seller must proceed with the final validation of the transaction.
This is done in 3 steps:
Step 1: 📌the seller enters the unique transaction ID,
Step 2: 📌then enters the SCS Code provided by the buyer,
Step 3: 📌finally scans the secure QR Code.
6️⃣ – PAYMENT RELEASE
When:
✅the SCS Code is correct;
✅the QR Code is valid;
the platform:
✔️definitively validates the transaction;
releases the Stripe payment;
💶transfers the money to the seller’s account. (N.B:ℹ️Transfers made by the platform to users’ accounts may take about 7 days to arrive in the associated bank account.) (Exact times depend on: the buyer’s bank, the payment network used, the payment provider)
📧Both users receive a confirmation of the validated transaction by email along with a 🧾receipt for the fees or commission deducted by the platform during the transaction.
==============================================================================
.
❌Cancellation of the transaction in progress
Cancellation by the buyer
The buyer can request cancellation before the final validation of a transaction in progress.
The seller must then: confirm the cancellation; or validate the transaction if the exchange has actually taken place.
If the seller confirms: the payment is refunded to the buyer.
If the seller does not respond: the refund is automatically processed after the 3-day deadline expires.
If the exchange has actually taken place, the seller can validate the transaction, and the payment is directly transferred to the seller.
Cancellation by the seller
The seller can also cancel the transaction while it is in progress.
In this case: the buyer is automatically refunded;
However, the seller is temporarily blocked 🚫; they can no longer post new ads for a set period of 3 days. (This measure is in place to ensure fairness between both parties⚖️; otherwise, only the buyer would be disadvantaged, since transfers initiated by the platform to user accounts take a few days to reach the associated bank accounts.
Once the period is over, they automatically regain posting access.
⏳Automatic Expirations
(The system specifically allows for: automating refunds; avoiding blocked transactions; protecting users in case of no response; automatically cleaning up old transaction data.)
Request Expiration
If the seller does not respond to the transaction or cancellation request within 3 days: the request expires automatically; the buyer is refunded; both parties receive a notification.
⏰Failure to validate payment by the seller!!!! (🚨Warning for the seller!!!)
After the scheduled physical transaction date, the seller must confirm that the transaction went well in order to validate the payment.
If no validation is performed within 3 days following the scheduled exchange date:
the platform considers that the transaction likely did not take place;
⚠️the payment is automatically canceled; the buyer is refunded❗;
an email is sent to the seller and the buyer to inform them of the deadline expiration.
This system is in place to ensure the optimal functioning of the service when the transaction is not confirmed.
⏱️Total process duration
The total duration of the transaction process (from the day of the transfer to the day of payment release/final transaction validation) is a 📅maximum of 7 days:
– 4 days maximum interval: from the day of the request to the physical transaction date
– 3 days maximum delay: from the day of the physical transaction to the final transaction validation
💰The commission is only earned by the platform once the transaction is definitively validated/payment released to the seller.
🗑️Automatic deletion of old transactions
To limit unnecessary data storage and keep the platform clean and efficient:
transactions older than 12 months are automatically deleted;
PDF files associated with transactions (buyer and seller documents) are also permanently deleted.
This deletion is performed automatically by the system.
==============================================================================
.
Why is ONECLICK Services secure 🛡️?
❌Attempted fraud –> 🚫Why it fails:
- ❌If A receives the code but does not give the item –> 🚫Impossible, because the exchange is SIMULTANEOUS.
- ❌If B receives the item but does not give the code –> 🚫Impossible, because the exchange is SIMULTANEOUS.
- ❌If A does not hand over the item but wants to claim payment (claiming to have handed it over) –> 🚫The proof that they handed over the item is the fact that they hold the code; -> they do not have it, therefore they did not hand over the item, consequently no payment to A.
- ❌If B receives the item but wants to cancel the transaction (claiming not to have received it) –> 🚫they must receive confirmation from A; -> A does not confirm because they hold the code, consequently no refund to B.
- ❌If A wants to deny B’s cancellation even though the exchange did not take place (claiming that it did) –> 🚫The proof that the exchange took place is the fact that they hold the code – they must therefore enter it; -> they do not have it, consequently unable to deny it.
✅ SIMULTANEOUS exchange item for code –> Consequence: 👉 No unilateral event allows for a gain.
