Product Journey Lab
This is an educational sandbox simulation — no money is collected and no card details are entered on Rabet.
The deterministic browser demo sends no financial request.
Owner
Understand preparation, operating responsibilities, and the commercial next step.
A clear installation request and understood responsibility boundary.
Request an installation purchase linkDeveloper
Inspect the project, review the file plan, then verify the path locally.
A reviewable integration backed by commands and tests.
Open the developer guideInvestor & partner
Assess the product through evidence, limitations, and a grounded roadmap before an investment or partnership decision.
An honest view of the current surface and partnership path.
Request a partnership discussionCustomer
Understand the redirect to the provider-hosted checkout and the final result.
A clear payment experience without unnecessary implementation detail.
View the educational simulation1. Choose context
Choose your role and demo environment.
Operating system
Project framework
Demo environment
Gateway path
Selected context: windows · laravel · local · upayments-knet
Context is ready for the safe local demo.
Why this step?
Presentation preferences stay in this browser only.
2. Inspect the project
The inspection shows what exists and what is missing.
$ rabet doctor- Read the selected context locally; the project is not uploaded.
Laravel— generator availableUPayments— foundation adapter; MyFatoorah v2 prototype deferred- Guided inspection complete; no file changed.
Why this step?
The demo presents rabet doctor and never sends secrets.
rabet doctor3. Review the plan
Review eight generated paths before any write.
- ADD
.env.rabet.exampleAdd configuration names only; no secrets.
- ADD
app/Models/RabetPayment.phpAdd an owner-scoped payment record with encrypted URLs and unique keys.
- ADD
app/Payment/PaymentController.phpAccept offer_id only, then select the amount and order from server configuration with an Idempotency-Key and database lock.
- ADD
app/Payment/UPaymentsClient.phpAdd a server client for link creation and status checks.
- ADD
app/Payment/WebhookController.phpAdd receipt followed by independent verification; never trust the browser return.
- ADD
config/rabet.phpAdd environment selection and configuration references.
- ADD
database/migrations/2026_07_17_000000_create_rabet_payments_table.phpAdd unique constraints, payment state, and an integer money unit.
- ADD
routes/rabet.phpAdd authenticated, rate-limited create/status routes and an independent webhook route.
Other project code remains untouched, and this plan is shown before any write.
Why this step?
rabet init plans the environment template, model, create controller, UPayments client, webhook controller, configuration, migration, and routes.
rabet init --dir /path/to/laravel4. Confirm and apply
No write or link simulation proceeds without explicit confirmation.
status: pending_confirmation
The MCP client stops here until a human reviews the eight paths and approves.
confirm:true is sent only after that human approval.
Why this step?
The MCP tool returns pending_confirmation until its client sends confirm:true after human approval.
rabet init --dir /path/to/laravel --apply5. Sandbox redirect
See an educational redirect to a provider-hosted checkout.
Educational UPayments / KNET redirect. The adapter maps payment_method:knet to paymentGateway.src=knet; for real use the provider must enable White Label and KNET on the merchant account, and Rabet cannot activate it.
An educational preview of a MyFatoorah-hosted path. A v2 prototype exists but is deferred from foundation; Sessions/Payments v3 and credentialed evidence remain future work.
Sandbox simulation only — no charge and no card data entered on Rabet.
Why this step?
This browser step is a non-financial simulation. Separately, a UPayments Sandbox transaction was evidenced on 2026-07-17; a live MyFatoorah check still requires a merchant secret.
6. Webhook and verification
The merchant server receives an event, then checks status with the provider.
- 1. Receive the event on the merchant server and extract a limited reference.
- 2. The scaffold creates a unique idempotency key and uses a database lock so the effect is recorded once; this runs in the merchant project, not the public site.
- 3. The server queries the provider independently; neither the webhook body nor browser return is the source of truth.
- 4. Only after CAPTURED, the merchant system atomically records the outcome once.
Why this step?
The listener handles repeat delivery and accepts success only after CAPTURED is verified.
rabet webhook listen --port 8787 --path /rabet/webhook7. Result and next action
Separate the demonstration from available code and merchant setup.
Owner summary
You saw inspection, planning, confirmation, and verification. Code and a manual request path are available; production needs merchant and provider setup.
Request installation manually — automated purchase is blockedDeveloper summary
You reviewed eight paths, the inspection command, the HITL decision, and CAPTURED verification. The component sends offer_id only; the server owns amount and order with idempotency and a database lock.
Open the implementation guideInvestor & partner summary
You saw a reviewable product and its current boundaries without turning the demo into revenue or payment proof.
Request a partnership discussion manuallyEnd-user summary
You saw the provider redirect and the merchant server verification that follows. This demo is not a Rabet purchase.
Review current statusWhy this step?
The lab itself sends no financial request. The separate UPayments Sandbox evidence is neither production nor real funds, and no public backend is deployed.