GridWindow FlexPay

Smarter EV charging. Payments tied to delivery. GridWindow balances shared power, protects driver consent during disruptions, and uses PayPal Sandbox to capture or void based on simulated outcomes.

Comment

GridWindow FlexPay | Final Devpost Submission

Short Description

AI-powered EV charging with intelligent scheduling, driver-approved recovery, and PayPal payments tied to verified simulated delivery.

1. Inspiration

An electric vehicle might remain plugged in overnight but need only a few hours of actual charging. That flexibility creates an opportunity: drivers could charge during lower-cost periods, while charging stations could distribute demand more efficiently across limited electrical capacity.

But there is a problem.

What happens when a charging station can no longer deliver what the driver already agreed to?

Imagine reserving an overnight charge, approving the price, and expecting your car to be ready at 7 AM. Halfway through the night, the charger loses power or the station's available capacity drops.

A typical scheduling optimizer might generate another schedule. But what if the new schedule changes the agreement? What if no feasible replacement exists? And what should happen to the payment?

We realized that optimizing charging is only half the problem. Keeping the promise made to the driver is the other half.

That inspired us to build GridWindow FlexPay, an AI-assisted EV charging platform that combines intelligent scheduling, physical constraint validation, driver consent, autonomous recovery, and PayPal payment processing.

Our vision is straightforward:

The driver approves a charging promise. The system works to keep it. If conditions change, the driver stays in control, and payment follows the verified outcome.

We wanted to build more than a charging calculator or payment checkout. We wanted a complete, working experience that demonstrates how intelligent automation and trustworthy financial systems can work together, including when things go wrong.

2. What it does

GridWindow FlexPay turns EV charging flexibility into a transparent agreement between the driver and the charging station.

It connects five essential capabilities: AI-assisted charging recommendations, feasible scheduling, explicit driver consent, intelligent disruption recovery, and delivery-linked PayPal payments.

Step 1: Tell GridWindow what you need

A driver can enter a request such as:

Find me 30 kWh before 7 AM, keep it under $20, and show me the cheapest feasible option.

Using Smart Charge, drivers can specify their energy requirements, departure deadline, charging preference, and budget.

Google Gemini assists with natural-language requests and explains the available options.

Behind the scenes, our scheduling engine evaluates:

  • Charging ports rated at 3.6, 7.2, and 11 kW.
  • A shared 24 kW demonstration-site power limit.
  • Existing charging reservations.
  • Arrival and departure deadlines.
  • Charging efficiency and energy requirements.
  • Synthetic building demand and electricity tariffs.
  • Driver preferences and operator economics.

The engine works in 15-minute intervals and independently validates proposed schedules before they are offered.

AI recommends. Deterministic software verifies.

This prevents the system from presenting attractive prices attached to physically impossible charging plans.

Step 2: Compare intelligent charging offers

GridWindow compares immediate charging with feasible flexible charging windows.

Drivers can select options based on cost, departure time, and charging preference, including Gentle Charging, which uses reduced power when feasible.

Our Flex Deal Agent explains the trade-offs between validated offers using server-verified data.

For example, in one recorded demonstration, the system presented two $11.45 charging plans, each offering $5.35 in modeled savings compared with charging immediately.

These savings are based on synthetic tariffs and operating assumptions, not measured customer electricity bills.

Step 3: Approve the agreement and authorize payment through PayPal

Once the driver selects an offer, GridWindow presents the exact commitment:

  • Required energy and charging window.
  • Merchant and agreed price.
  • Departure deadline.
  • Payment authorization amount.
  • Approval and expiration conditions.

The driver explicitly consents to those terms and completes PayPal Sandbox buyer approval.

The important difference: GridWindow authorizes the payment but does not capture it simply because the reservation was created.

The authorized amount remains on hold while the simulated charging outcome is unresolved.

The payment lifecycle is:

Driver consent → PayPal authorization → Simulated charging → Verified delivery → Capture or void

An authorization is a hold, not an immediate charge or escrow.

Step 4: Recover intelligently when something goes wrong

This is one of GridWindow's most distinctive capabilities.

A charging reservation can become disrupted by a synthetic charger outage, reduced charger power, lower site capacity, or an earlier departure deadline.

Rather than blindly generating another schedule, GridWindow runs a traceable recovery workflow.

It identifies the disturbance, evaluates potential repairs, checks physical feasibility, determines whether new driver consent is required, and records the resulting schedule and payment state.

There are three possible outcomes:

Automatic recovery: The system finds a feasible adjustment that remains within the terms the driver already approved.

Driver-approved recovery: A feasible adjustment changes the agreement, so the system presents the revised plan and waits for explicit driver approval before committing it.

Infeasible recovery: No valid replacement can satisfy the constraints. GridWindow refuses the impossible schedule, preserves the appropriate financial state, and requests operator resolution when needed.

The system also protects previously delivered energy, existing reservations, and the original agreement.

The platform does not pretend every problem has a solution. Sometimes the correct decision is to stop and ask for human intervention.

Step 5: Settle according to the outcome

Once qualifying simulated energy delivery has completed, GridWindow can capture the previously authorized amount through PayPal Sandbox.

For eligible operator-attributed failures, the application can instead void the authorization.

If responsibility is unresolved, the system does not automatically move money.

Our FlexReceipt connects the original charging commitment, simulated delivered energy, and PayPal-confirmed financial outcome.

Three demonstrated recovery and payment outcomes

Scenario System behavior PayPal outcome
November 23: Driver-approved recovery Charger power reduction triggered a revised plan. The driver approved the change, schedule version 2 was committed, and 30.015 kWh was simulated as delivered. $13.04 captured, confirmed by PayPal Sandbox provider read-back and a verified webhook.
November 25: Infeasible recovery The system determined that no feasible repair existed. Responsibility was unresolved, and operator review was required. $13.03 authorization remained held. $0.00 captured. No void.
Separate operator-attributed failure The system verified that no acceptable repair existed and attributed responsibility to the operator. Authorization voided through PayPal Sandbox. $0.00 collected.

These are three distinct examples demonstrating that recovery decisions and financial decisions are not interchangeable.

An infeasible recovery does not automatically authorize a refund, capture, or void.

One platform for drivers and operators

For drivers, GridWindow provides guided charging requests, understandable recommendations, transparent pricing, consent controls, recovery approvals, and printable receipts.

For operators, the platform provides:

  • An AG Grid reservation and payment management console.
  • A Bryntum charging scheduler with original, proposed, and recovered schedules.
  • Searchable and filterable reservation records.
  • Recorded disturbances and seven-step recovery traces.
  • Schedule version history.
  • Payment authorization, capture, and void status.
  • Reconciliation evidence and operational visibility.

GridWindow is a publicly deployed software prototype. Charging sessions, site loads, tariffs, and disturbances are synthetic. Payment operations use real PayPal Sandbox APIs with test funds.

Explore the project:

Live Application | Smart Charge | Judge Guide

3. How we built it

We designed GridWindow FlexPay as a complete software platform rather than a single AI prompt connected to a payment button.

The application uses Next.js 16, React 19, TypeScript, Tailwind CSS, Zod, PostgreSQL, and PGlite, with distinct layers for scheduling, validation, AI assistance, recovery orchestration, payments, and persistent event history.

Our architecture follows one principle:

AI can propose and explain decisions, but trusted application logic must validate and authorize consequential actions.

PayPal: Building payments around delivery

We integrated the PayPal Orders and Payments APIs in Sandbox mode to support the complete payment lifecycle.

This includes:

  • Order creation and buyer approval.
  • Payment authorization.
  • Conditional capture after qualifying simulated delivery.
  • Authorization voids for eligible failures.
  • Webhook signature verification.
  • Provider-state reconciliation.
  • Idempotent payment operations.
  • Protection against duplicate capture or void requests.
  • Immutable approved terms and server-side payment validation.

Instead of treating payment approval as the final step, GridWindow keeps track of what was agreed, what was simulated as delivered, and what PayPal actually confirmed.

An authorization is not reported as a completed payment. A local application status change is not treated as proof of provider settlement.

This distinction becomes essential when a charging session is delayed, interrupted, or impossible to complete.

Google Gemini: Making charging decisions understandable

Gemini supports natural-language charging requests, offer explanations, and recommendations among eligible alternatives.

Our Flex Deal Agent uses validated charging offers instead of allowing AI to invent its own prices or operating assumptions.

OpenRouter provides an additional model backup route.

When AI services are unavailable or rate-limited, the application can continue through a clearly labeled deterministic fallback.

The model never receives authority to override the scheduling validator, change approved commercial terms, or independently move funds.

Agentic commerce through MCP

We also built a seven-tool Model Context Protocol (MCP) server, allowing compatible AI clients to interact with GridWindow's charging workflows.

An agent can inspect station information, compare eligible charging offers, obtain recommendations, discover relevant EV accessories, and prepare a PayPal checkout when requested.

But the financial boundary remains explicit.

An AI agent can prepare the transaction. Only the buyer can approve it.

The agent cannot independently authorize payment on behalf of the buyer, capture funds, or bypass server-validated prices.

This creates a practical example of agent-assisted commerce where automation improves convenience without removing human financial control.

Deterministic scheduling and recovery

Our optimization engine considers energy demand, charging efficiency, port power, site capacity, existing reservations, deadlines, and modeled electricity costs.

A separate validation layer checks the feasibility of every proposed schedule.

We use integer-based quantities such as watts, watt-hours, and cents to reduce unnecessary rounding errors.

The recovery engine builds on the same approach.

When conditions change, it stores the disturbance, evaluates candidate schedules, validates constraints, identifies consent requirements, and tracks committed schedule versions.

Previously delivered energy and other reservations remain protected.

The recovery workflow also preserves an auditable sequence of decisions, including the final financial state.

Five sponsor technologies integrated into the product

We integrated five additional sponsor technologies into identifiable, working features.

Technology Implementation Value
AG Grid Searchable, sortable, filterable operator reservation tables, payment status, attention views, and CSV export Helps operators identify and manage reservations requiring attention
Bryntum Scheduler Original, proposed, and recovered charging timelines with capacity context and date navigation Makes scheduling decisions and recovery changes visually understandable
APIMatic Public OpenAPI developer portal, endpoint documentation, request examples, and generated TypeScript SDK documentation Makes GridWindow APIs easier for developers to inspect and integrate
Channel3 Live third-party EV accessory discovery in the Rewards experience Connects the charging journey to relevant products from external merchants
Render Public hosting for the application and separately deployed developer portal Makes the working product and API documentation accessible online

The sponsor tools solve different needs within the product rather than serving as isolated demonstrations.

AG Grid helps answer, "Which reservation needs attention?"

Bryntum helps answer, "What changed in the charging schedule?"

APIMatic provides an interface for external developers to understand and integrate with the platform.

Channel3 adds relevant product discovery through third-party merchant listings. GridWindow does not sell those items, and modeled charging savings are not actual cash rewards.

Render hosts the public application and developer portal.

Testing and deployment

We used GitHub Actions, automated unit and integration tests, browser tests, and release checks to validate the system.

The application is publicly deployed, with source code, developer documentation, and instructions for running a local MOCK-mode demonstration without personal PayPal, AI, or production database credentials.

Technical resources:

GitHub Repository | Developer Portal | Judge Guide

4. Challenges we ran into

Making charging offers physically achievable

The cheapest charging window is not necessarily a feasible one.

A proposed schedule must respect the driver's deadline, each port's power limit, existing reservations, and the site's shared electrical capacity.

We separated optimization from independent validation so an attractive offer could never override the physical constraints.

This became particularly important when a disturbance made a previously feasible schedule impossible.

Handling the full PayPal payment lifecycle

Payment integration required substantially more than redirecting a driver to checkout.

Order creation, buyer approval, authorization, capture, void, webhooks, and reconciliation are separate states.

Webhooks can arrive late or more than once. A session can remain authorized while the charging outcome is unresolved.

We introduced idempotency, verified webhooks, provider read-back, and explicit settlement states to prevent the application from confusing money on hold with money collected.

Recovering without violating driver consent

A replacement charging plan may be physically feasible but commercially different from what the driver approved.

We implemented schedule versioning, candidate validation, stale-decision protection, and explicit reapproval when changes fall outside previously accepted terms.

This lets the system adapt without silently rewriting the agreement.

Making AI useful without giving it financial authority

Model services can experience rate limits, outages, or unexpected responses.

We could not allow those limitations to compromise charging feasibility or payment correctness.

Our solution was to let AI assist with interpretation, explanation, and recommendations while trusted server logic enforces constraints and settlement policies.

When a deterministic fallback is used, the application identifies it rather than presenting the result as an AI decision.

Making complex operations understandable

Grid scheduling, charging commitments, recovery decisions, and payment states can be difficult to follow.

We addressed this through guided driver screens, clearly labeled payment statuses, Bryntum timeline comparisons, AG Grid operator views, seven-step recovery traces, and FlexReceipt.

We also corrected the recovery workflow's financial-step presentation so completion reflects the actual settlement evidence rather than appearing complete prematurely.

The challenge was not just building each component. It was making the entire system feel like one understandable product.

5. Accomplishments that we're proud of

1. Built and verified a complete PayPal payment journey

We implemented actual PayPal Sandbox authorization, capture, and void operations using test funds.

Our hosted evidence includes successful capture after qualifying simulated energy delivery, zero-collection voids after eligible operator-attributed failures, verified webhook processing, and provider-state reconciliation.

We also demonstrated that an infeasible recovery with unresolved responsibility can correctly leave the authorization held without capturing or voiding it.

Our biggest accomplishment was making the payment outcome dependent on the recorded service outcome and applicable settlement policy, rather than simply charging at checkout.

2. Measured scheduling performance across 1,500 synthetic requests

We evaluated four scheduling strategies over 500 seeded synthetic nights and 1,500 charging requests, using consistent modeled operating assumptions.

Scheduling strategy Requests served Mean modeled cost per served session Mean site peak
Immediate charging 1,246 $10.61 22.1 kW
Static off-peak 1,024 $6.01 20.2 kW
Greedy tariff scheduling 1,243 $6.86 21.9 kW
GridWindow optimized 1,254 $5.44 17.6 kW

Compared with immediate charging, GridWindow's optimized policy achieved:

  • 48.7% lower mean modeled energy cost per served session.
  • 20.4% lower mean site peak.
  • 1,254 requests served, eight more than immediate charging.
  • Zero hard-constraint violations in the validated benchmark schedules.

These findings demonstrate the potential of combining flexibility-aware scheduling with strict physical validation.

We also report the limitations.

There were 125 unfavorable pairwise cost comparisons, and 246 requests were physically infeasible for the optimized policy.

The comparison uses modeled costs for the requests served by each policy. It does not establish identical-session customer savings, and these numbers are not measured outcomes from real charging infrastructure.

We believe reporting limitations is just as important as reporting improvements.

3. Created a recovery engine that can say no

We built a system capable of evaluating disruptions, generating candidate repairs, validating physical constraints, preserving driver consent, and recording financial consequences.

The November 23 and November 25 scenarios illustrate two different decisions: approving and completing a valid revised plan versus rejecting an impossible one and preserving the authorization.

The platform does not silently change commitments or assume that every disruption can be solved.

4. Completed extensive automated testing

Our final documented verification includes:

  • 1,023 passing Vitest unit and integration tests, 12 skipped, zero failures.
  • 131 passing Playwright browser tests across desktop, mobile, and tablet, six skipped, zero failures.
  • Passing TypeScript, lint, production build, and release security checks.
  • Separate hosted verification of PayPal Sandbox capture and void operations.
  • Working implementations involving Gemini, MCP, Bryntum, AG Grid, APIMatic, Channel3, and Render.

That represents 1,154 passing automated tests across the two main suites.

The automated suites use isolated data and a MOCK payment provider. Genuine PayPal Sandbox results were independently verified on the hosted application rather than inferred from MOCK testing.

5. Delivered a connected, inspectable product

GridWindow is more than a collection of backend services.

It includes a public driver experience, charging comparison tools, a functioning operator console, recovery workflows, financial records, developer documentation, and a reproducible local setup.

Judges can inspect both the happy path and failure scenarios.

The application demonstrates how charging optimization, AI assistance, consent management, and payment protection can operate as one coherent experience.

Explore the evidence:

Judge Guide | Verified Integration Evidence | Latest Release

6. What we learned

We began by trying to optimize EV charging. We ended up building a system designed to preserve trust when the original plan changes.

Three lessons shaped how we approached the project.

First, optimization must be verifiable.

An inexpensive schedule is not valuable if the charger cannot deliver the required energy before departure. Every recommendation needs independent validation against physical and commercial constraints.

Second, autonomous recovery must respect consent.

An automated system should not assume permission to change an agreement simply because it has found a new technically feasible solution.

The driver's approval applies to specific terms, and meaningful changes require another decision.

Third, payment must reflect the service outcome.

Authorizing a payment and collecting it are not the same action.

A successful booking does not guarantee successful delivery. Likewise, an interrupted session does not automatically determine whether money should be captured or voided.

The correct decision requires evidence, responsibility attribution, and a defined settlement policy.

We also learned that AI is most useful when its authority is clearly bounded.

Gemini makes it easier for drivers to express their needs and understand their options. Deterministic software handles pricing, feasibility, consent, and financial enforcement.

That separation allows the platform to remain understandable and operationally controlled even when AI services are unavailable.

Ultimately, the most valuable feature was not making every charging plan succeed. It was building a system that can explain when a plan cannot succeed and respond responsibly.

7. What's next for GridWindow FlexPay

Our next goal is to move from a controlled simulation toward a real-world charging-site pilot.

The current prototype demonstrates the scheduling, consent, recovery, and payment architecture. The next stage is validating those workflows against physical charging infrastructure and measured operational data.

Our roadmap includes:

Real charger connectivity: Integrate compatible charging hardware, actual session telemetry, metered energy delivery, and charger fault information.

Measured operational data: Replace synthetic tariffs, site demand, and building load with real inputs to evaluate whether the modeled benefits translate into measurable outcomes.

Production-grade financial operations: Strengthen operator identity, permissions, monitoring, and payment controls before supporting commercial transactions.

More advanced recovery: Improve forecast-aware replanning, disturbance explanations, and multi-site coordination while preserving deterministic validation and explicit consent.

Real-world impact measurement: Evaluate completed charging sessions, delivered energy, payment exceptions, driver approvals, and site-level cost outcomes through a controlled pilot.

We would only claim actual energy savings or commercial readiness after validating the platform under real operating conditions.

Our long-term vision is not to let AI decide what drivers pay. It is to let AI help people make better charging decisions, while the system ensures that charging commitments and payments remain accountable.

Optional Sponsor-Specific Answer: AG Grid

AG Grid is a functional component of our operator console, not an isolated demonstration.

We integrated it to manage charging reservations alongside payment and charging states. Operators can search, sort, filter, identify records requiring attention, and export reservation data.

This becomes particularly valuable when a charging disruption occurs because the operator needs to understand which reservation is affected and what financial state applies.

We paired AG Grid with Bryntum Scheduler to provide two complementary views.

AG Grid answers, "Which reservation requires attention?" Bryntum answers, "How has the charging schedule changed?"

Together, they make the operational impact of charging decisions easier to inspect and manage.

Our implementation uses AG Grid. We are not claiming features built with AG Charts or AG Studio.

Optional Sponsor-Specific Answer: APIMatic

We used APIMatic to make GridWindow's APIs accessible through a public developer experience.

Starting with the application's OpenAPI contract, we built a developer portal containing endpoint references, request examples, and generated TypeScript SDK documentation.

This helps developers understand the API structure, explore the available operations, and prepare integrations without having to navigate the source code first.

The APIMatic-powered portal is deployed separately on Render and is publicly accessible.

Explore the Developer Portal

Note: This describes our verified APIMatic integration. We are not claiming use of the separate APIMatic Context Plugin unless that workflow is independently confirmed.

Built With

Share this project:

Updates

Submission history