Plan B Booking

• 

  Review before approving: same €60 deposit, €0 extra charge, €120 balance. PayPal sandbox and synthetic sessions.

• 

  No match, no commitment. Separate example: clarify requirements before approving any session or starting a payment.

• 

  One record: original agreement, approved change, sandbox capture and completed refund. No held deposit or remaining balance.

Inspiration

An outdoor photo session is more than a calendar slot. It is an agreement about a place, a time and a payment. When the plan changes, those pieces can drift apart: a new date in one conversation, the original deposit elsewhere, and a customer wondering whether they need to pay again.

Plan B focuses on that second decision. It helps a photographer review a changed session while keeping the payment history attached to the same booking.

What it does

The prototype brings the session request, supplied options, human approval and deposit state into one local workspace. The example session costs €180, with a €60 deposit. Moving the session retains that deposit; approved cancellation returns it and waives the remaining balance under an explicit fictional policy.

A local language model proposes a compatible option. The application checks explicit requirements against the supplied sessions and builds the visible explanation from checked session facts or its review policy. A proposal does not approve a booking, change an amount or move money. Before committing a change, the person reviews the original and proposed agreement and its financial effect.

The decision log preserves approved revisions. A readable booking record exports the agreement, payment references and export time, so the result can be reviewed outside the app.

How I built it

Plan B uses Node.js and browser JavaScript, HTML and CSS without a frontend build step. Qwen3-VL 8B, running locally through Ollama, produces structured proposals. Application validation checks the result before it reaches a decision screen. The default rules preview is labelled as a preview and is not presented as AI.

The payment layer keeps separate demo and sandbox data. Payment operation identifiers are persisted before requests, stale approvals are rejected, and uncertain provider results remain unresolved rather than being treated as successful. Rescheduling does not create another charge.

The PayPal REST adapter is restricted to sandbox. A real test journey completed an approved €60 capture, moved the session while preserving the same capture and collected no second deposit, then completed a €60 refund after separate cancellation approval. This is evidence for that bounded sandbox journey, not a claim of production reliability. Automated payment tests additionally exercise offline and HTTP-stub failure cases.

I used AI coding assistance to implement and review the prototype. The repository documents the synthetic scenarios, validation results and limits of the demonstration. The final backend suite passed 40 automated tests; those payment tests use offline or HTTP stubs, while the completed PayPal sandbox journey is documented separately.

Challenges I ran into

The most important boundary was between a suggestion and a commitment. A request to move a session is not approval of a different date. A request to cancel is not proof that a refund has completed. Keeping those states separate makes the flow more understandable and easier to test.

Another challenge appeared in a real test: the model selected the right session but described its year incorrectly. I kept the validated selection and replaced free-form model explanations with checked fixture facts. Earlier trials also showed that unfamiliar requests can produce confident guesses. Known cases now stop for clarification; this does not mean every ambiguity is understood.

Accomplishments

The local prototype carries a booking through proposal, a real sandbox deposit, a reviewed change and a separately approved sandbox refund. The change preserved the same capture reference, and the completed cancellation left no held deposit or remaining example balance. Its decision log and readable export keep the agreement and payment record together.

What I learned

A payment workflow needs to explain what is still unknown as clearly as what has completed. The useful product work is not only the happy path; it is the moment when an option does not fit, an approval has become stale, or a provider response is still pending.

What is next

The next step is to test the recovery decisions with photographers using new fictional scenarios, especially when no alternative fits. The current prototype uses four supplied session options, fictional weather and a fictional cancellation policy. Live calendar availability, multi-user access and production payment operations remain future work.

Run it and review the evidence

The public repository includes all application source, an MIT license, setup instructions and the sandbox runbook. Run the offline preview with Node.js 20.12+ and npm start; enable the local Ollama model and configure your own PayPal sandbox credentials to reproduce the AI and payment path. The README explains the separate preview, AI and sandbox modes, and how to obtain the required free developer access. No private keys or account data are distributed.

The updated demonstration uses my own narration and English captions over real browser recordings of the working prototype. It shows session selection, PayPal sandbox approval, deposit confirmation, a reviewed date change, separate cancellation approval, the completed refund and the saved decision log after a reload. It is edited across takes; model waits and the separate no-match example are labelled. All sessions and funds shown are test data.

Built With

• css3
• html5
• javascript
• node.js
• ollama
• paypal
• qwen3-vl