Purpose. This document outlines the proposed payment, escrow, wallet and settlement flows required for KIK Konnect and the areas where we would like Pandascrow's technical and commercial guidance.
The core objective is to provide customers with payment protection throughout a service transaction, while enabling appropriate settlement to service providers, KIK Konnect and, where supported, assigned KIK agents.
We have presented alternative structures in areas where Pandascrow's infrastructure may provide different implementation options.
This applies to services where the price is already known before the customer proceeds with the booking.
Customer selects a fixed-price service costing ₦40,000. KIK creates Booking #KK1001, Service Amount ₦40,000, Service Status: Awaiting Payment.
The required ₦40,000 is secured against Booking #KK1001 through the applicable Pandascrow-supported funding structure. Once successful funding is confirmed through API/webhook: Payment Status SECURED / PROTECTED, Protected Amount ₦40,000. The customer sees that the payment is protected. The provider receives confirmation that the required payment has been secured and can proceed with the service.
The service progresses through KIK Konnect's operational stages: Accepted → En Route → Arrived → In Progress → Pending Customer Confirmation. Throughout this period, the applicable ₦40,000 remains protected against the transaction.
The provider marks the service as completed. The customer is then required to confirm whether the service has been satisfactorily completed. If the customer confirms, the transaction becomes eligible for settlement. If the customer raises a dispute, the applicable payment remains protected and moves into the dispute-resolution process.
We would like to understand which of the following settlement structures Pandascrow can support.
Where Pandascrow supports multiple beneficiaries and independently controlled settlements, our preferred flow is:
| Beneficiary | Amount |
| Service Provider | ₦36,000 |
| Assigned KIK Agent | ₦800 |
| KIK Konnect | ₦3,200 |
| Total Settlement | ₦40,000 |
The agent's ₦800 represents 20% of KIK Konnect's original ₦4,000 platform commission.
We would ideally like the agent settlement to have an independent status. For example, there may be circumstances where:
This may be required where an operational issue concerning the assigned agent needs to be resolved without affecting the service provider's legitimate payment. Once the issue is resolved: Agent Commission RELEASED.
We would therefore like Pandascrow to confirm whether its infrastructure allows:
If supported, Option A would be KIK Konnect's preferred settlement architecture.
If Pandascrow cannot independently manage the agent settlement layer described above, the alternative structure would be:
| Beneficiary | Amount |
| Service Provider | ₦36,000 |
| KIK Konnect | ₦4,000 |
KIK's internal commission ledger would subsequently allocate: ₦800 to Agent Commission and ₦3,200 to KIK Net Revenue. The agent's internal commission status could then be Pending / Available / On Hold / Paid. KIK would subsequently settle the agent from its earned platform commission.
This applies where the final service price cannot be determined until a service provider has inspected the work required. This transaction has two distinct financial stages: Stage A — Inspection, and Stage B — Main Service after quotation acceptance.
Customer requests a service requiring inspection. KIK creates Booking #KK2001, Inspection Fee ₦5,000, Main Service Amount Pending Inspection/Quotation.
Before the provider proceeds with the inspection, the customer is required to secure the ₦5,000 inspection fee. The inspection payment is associated with Booking #KK2001 — Inspection Transaction. Once funding is confirmed: Inspection Payment ₦5,000, Status SECURED / PROTECTED. The provider receives confirmation: Inspection Payment Secured — You May Proceed.
The ₦5,000 inspection fee remains protected while the inspection service is being carried out. The inspection progresses through: Inspection Accepted → En Route → Arrived → Inspection In Progress → Inspection Completed. The inspection fee should not be released merely because the provider accepted the inspection request; it remains protected while the inspection is ongoing.
After performing the inspection, the provider submits the quotation for the main service through KIK Konnect. Example: Inspection Fee ₦5,000, Inspection Completed, Main Service Quote ₦40,000. The customer receives Provider Quote ₦40,000 with Accept Quote or Reject Quote.
Once the inspection has been successfully completed according to the applicable conditions, the ₦5,000 inspection transaction becomes eligible for settlement. The inspection transaction is financially separate from the main-service transaction. The inspection fee represents payment for the inspection/diagnostic service that has already been performed. Therefore, where the inspection was properly completed, a customer's subsequent decision to reject the main-service quotation does not automatically reverse the inspection transaction, subject to the applicable dispute/refund rules. The inspection transaction can follow the same applicable Provider/KIK/Agent commission structure.
If the customer rejects the quote, no main-service payment is required. The booking may end as Inspection Completed / Main Quote Rejected. The completed inspection transaction remains recorded separately.
If the customer accepts the quote (Accepted Quote ₦40,000), acceptance of the quotation does not by itself authorize the provider to begin the main work. The required ₦40,000 must first be secured/protected.
KIK creates another transaction associated with the same booking: Booking #KK2001, Transaction 1 Inspection ₦5,000, Transaction 2 Main Service ₦40,000. The customer secures the ₦40,000. Once Pandascrow confirms successful funding: Main Service Payment ₦40,000, Status SECURED / PROTECTED. Provider receives: Main Service Payment Secured — Work May Begin. Only then does the main job proceed.
Main Service Progress: Accepted/Approved → In Progress → Pending Customer Confirmation → Customer Confirms OR Raises Dispute → Settlement / Dispute Resolution. The main-service transaction then follows either Settlement Option A or Settlement Option B described above.
KIK Konnect would like to understand both funding structures that Pandascrow may be able to support. We have not predetermined which structure must be used. We would like Pandascrow to advise on the appropriate architecture based on its existing wallet, escrow, custody and API infrastructure.
If supported by Pandascrow's infrastructure, a customer may have an available payment balance accessible through the KIK Konnect experience.
Alternatively, Pandascrow may recommend that customers pay directly for individual transactions without maintaining a pre-funded balance.
The customer funding structure and provider settlement structure should be treated independently. Regardless of whether KIK Konnect uses customer wallet funding or direct job-specific payments, the service provider must be able to receive their entitlement once an escrow transaction becomes eligible for release. We would therefore like Pandascrow to clarify which provider settlement structure its infrastructure supports.
Upon successful service completion and escrow release, Pandascrow settles the provider's entitlement directly to the provider's registered settlement/bank account.
Alternatively, where supported by Pandascrow, released provider earnings may first become available within a provider wallet/earnings balance.
We would also like to understand whether provider settlement can be placed on hold where appropriate.
KIK Konnect is open to the architecture Pandascrow recommends based on its available infrastructure.
If a customer raises a dispute before final settlement, the applicable protected transaction should move to DISPUTED / ON HOLD. The funds should remain protected while the dispute is investigated.
If the service is determined to have been properly completed, the transaction is released according to the applicable Provider/KIK/Agent settlement structure.
If the applicable conditions justify a complete refund: ₦40,000 to Customer. Provider entitlement becomes zero for that transaction. Applicable KIK/agent commissions should also be treated according to the agreed refund rules.
Regardless of the final customer funding and provider settlement structures, KIK Konnect will maintain an internal ledger for transaction tracking, accounting and reconciliation. The ledger should track information such as:
For inspection-based services, the ledger must allow multiple financial transactions to be associated with one booking. Example: Booking #KK2001 → Inspection Transaction #1 ₦5,000 → Main Service Transaction #2 ₦40,000. Any approved additional work may similarly create an additional transaction associated with the same booking.
Customer Books Service → Payment Secured → Funds Protected → Provider Performs Service → Customer Confirms OR Disputes → Settlement / Dispute Resolution.
Preferred Settlement: Provider + Agent + KIK through Pandascrow. OR Alternative Settlement: Provider + KIK through Pandascrow → KIK manages Agent Commission internally.
Customer Requests Inspection → Inspection Fee Secured → Inspection Fee Protected While Inspection Is Ongoing → Provider Performs Inspection → Provider Completes Inspection & Submits Quote → Inspection Transaction Becomes Eligible for Settlement → Customer Accepts or Rejects Main Quote.
If rejected: Transaction Ends After Inspection. If accepted: Main Service Payment Is Secured → Main Service Payment Protected → Provider Begins Main Work → Service Completed → Customer Confirms OR Disputes → Settlement / Partial Resolution / Refund.
Option A — Customer Wallet: Customer Funds Balance → Available Balance → Amount Allocated to Booking → Protected Balance for Specific Job, while remaining funds remain Available Balance.
Option B — Direct Job Payment: Customer Pays Directly for Specific Booking → Payment Protected for that Booking.
Independent of the customer funding method: Option A — Direct Provider Settlement: Escrow Released → Provider Entitlement Sent to Registered Bank/Settlement Account. Option B — Provider Earnings Wallet: Escrow Released → Provider Available Earnings → Provider Withdraws to Registered Bank Account.
Preferred: Pandascrow Settles Agent Directly, with the ability for KIK to place the agent portion on hold independently where required. Alternative: Pandascrow Settles KIK's Gross Commission → KIK Allocates and Pays Agent Commission Internally.
The customer experience should remain straightforward regardless of the underlying architecture: Payment Secured → Payment Protected → Service Performed → Customer Confirmation or Dispute → Appropriate Settlement/Refund.
We would like to use our discussion with Pandascrow to determine the most appropriate combination of Customer Wallet vs Direct Job Payment, Direct Provider Settlement vs Provider Earnings Wallet, and Three-Way Provider/Agent/KIK Settlement vs Provider/KIK Settlement with Internal Agent Commission, based on Pandascrow's existing API, wallet, escrow, custody, compliance and commercial infrastructure.