Xicar

Product updates

What's new
at Xicar

A clear record of product improvements, fixes, and operational updates, with the reason each change matters.

Browse updates

Latest updates

September 2026

Wallet, payments, referrals, and the XICAR web platform converge

September 29 brought the ride, wallet, affiliate, referral, and web surfaces closer together around a shared payment and referral architecture.

Ride payments now use xicar-wallet as the source of truth for held fares, settlement, refunds, tips, cancellation credits, and recovery. Payment choices were expanded so GCash rides can be paid directly at booking, tips can use Cash, XICAR Wallet, or GCash, and cancellation fees can be settled through the wallet or GCash. Driver trip earnings use a configurable hold period and become withdrawable after 15 minutes once the related ride has finished settling.

The customer beta app also enables the My Wallet tab by default so testers can exercise wallet balance, top-up, withdrawal, and ride-payment flows. Follow-up fixes repaired beta compilation after the payment and referral reconciliation and preserved withdrawal request IDs across ambiguous retries so repeated requests remain idempotent.

Referral sign-up moves behind Affiliate

The referral sign-up flow now separates public referral handling from ride-account creation. The referral web calls Affiliate for invite validation, OTP orchestration, account sign-up, and referral binding, while the ride backend keeps only the internal operations it uniquely owns.

Affiliate also gained durable commission delivery and reversal behavior. Failed commission deliveries can be retried, refunded rides can reverse their commissions, and wallet calls use deterministic request identities so the same operation is not applied twice.

The standalone referral page remains the current customer-facing referral surface. It validates invite codes before requesting an SMS and uses Affiliate as its backend instead of relying on the mobile app login flow.

XICAR web moves to Celld

The former marketing repository is now the broader Xicar-PH/web surface. The existing marketing application has been moved into apps/marketing as the first workspace application, while deploy/web acts as the shared composition layer for the final web artifact.

The web deployment path now uses Celld for both beta and production fleets. GitHub Actions builds the static site, keeps beta and production deployments isolated, and publishes the selected artifact to the corresponding Celld-backed fleet storage.

This structure prepares the repository to host additional XICAR web applications alongside marketing, including the referral experience and shared-ride detail pages. Those applications have not been moved into Xicar-PH/web yet; the September 29 work establishes the repository and deployment boundaries needed to add them without creating separate deployment stacks.

Ride reliability fixes

The same integration work also repaired multi-stop route and fare calculation for rides with intermediate waypoints and added the missing payment columns required by the online-payment flow, preventing schema mismatches during ride creation.

References

Ride-hailing improves discounts, ratings, wallet groundwork, and production delivery

Ride-hailing now applies the single best eligible location discount to a fare instead of combining competing promotions. The selected discount is reflected consistently in customer and attendant quotes and bookings, usage limits are rechecked during booking creation, and attribution is preserved for admin reporting.

Production booking migration stabilization

The transition to normalized booking_stops was hardened through a series of production fixes for mixed-version deployments. Customer and attendant booking creation temporarily keep legacy endpoint fields synchronized with booking_stops, while reads can fall back safely when older rows do not yet have stop records.

The migration path now accepts historical routes whose optional place IDs are missing when their coordinates still identify the same endpoints. Long-running historical stop reconciliation was moved out of application startup so web containers can begin serving without waiting for an unbounded backfill.

Startup migration ownership was returned to the web role, health-check timing was restored to the normal deployment window, and matching jobs now strip loaded Eloquent relations before entering the queue so older workers do not fail when newer producers know about the stops relationship.

An explicit route compatibility boundary now normalizes supported legacy and current booking requests into the canonical route model and presents a compatible response shape for deployed customer and driver versions. Together, these changes keep the stop migration additive rather than requiring an all-at-once backend cutover.

Wallet and referral groundwork

The ride-hailing mirror merged the broader customer and driver wallet, referral, commission, cancellation/refund, and driver-onboarding groundwork. This introduced the application surfaces and backend integration points that the settlement, payment-choice, and Affiliate-backed referral work built on the following day.

The mirror beta history was also synchronized with the corresponding ride-hailing beta history without resetting mirror-only changes, keeping the two lines of work aligned before the larger payment and referral reconciliation.

A stale import of the discontinued device-security service was removed from the customer referral service, restoring the Customer Beta Android build without bringing the removed security-tracking implementation back.

Rating experience

Customer rating prompts are less intrusive and more predictable. The home screen only prompts once per app run for the most recent eligible completed ride, while ride history now opens the rating sheet immediately and loads any missing driver details in the background. This avoids repeated prompts and removes the wait before a customer can start rating from history.

Attendant Android production distribution

The attendant Android production build is now prepared for Firebase App Distribution instead of Google Play Internal Testing. The workflow builds a production-signed APK, derives the Firebase app ID from the production configuration, and temporarily disables attendant production iOS while leaving other mobile production delivery paths unchanged.

Admin discount management

The admin location-discount form now explains maximum discount and usage-limit fields more clearly. API validation or save errors stay visible in the open modal instead of silently closing it, while true network failures continue to use the existing offline queue behavior.

References

Canonical ride-hailing promotion and production deployment hardening

The ride-hailing mirror beta history was promoted into the canonical Xicar-PH/ride-hailing repository while preserving both histories. This moved the accumulated beta work back into the primary repository without flattening or discarding the independent main-branch commits.

Production migration ownership and health checks

The backend deployment model was tightened around explicit migration ownership. Ride-hailing, wallet, and affiliate now keep startup database migrations on the web role instead of allowing every long-running container to compete for the same migration gate.

For ride-hailing, startup work was reduced so queue and scheduler processes can reach their actual workloads without waiting behind web migrations. The web health-check window was also adjusted for migration-aware startup behavior.

Wallet queue and scheduler images were hardened for Coolify by removing the inherited web-server health probe and adding explicit health checks suitable for their long-running worker roles. This prevents healthy worker containers from being rolled back simply because they do not expose the FrankenPHP/Caddy port used by the web image.

Service configuration cleanup

Wallet deployment configuration was simplified around the active PostgreSQL and service-authentication contract, including direct and optional pooled database URLs and explicit wallet service credentials. Wallet and Affiliate integration documentation was also updated so the expected service-specific credentials are clearer across the ride, wallet, and affiliate boundaries.

Ride-hailing backend removes unused GraphQL surface

The ride-hailing backend removed its unused Lighthouse and GraphQL scaffold, leaving the service focused on its existing REST and WebSocket interfaces.

The removed layer only exposed the default GraphQL hello query and was not used by ride-hailing business operations or mobile clients. Removing it also drops the associated Composer dependencies, schema validation step, configuration, environment settings, resolver, and GraphQL-specific tests.

A regression test now verifies that the backend does not expose a /graphql endpoint or GraphQL route name. No database migration, REST contract, or WebSocket contract changed as part of this cleanup.

Safer trip completion and booking-stop rollout

Trip completion now protects against delayed retries accidentally closing a driver’s newer ride. When a booking ID is supplied to the end-trip request, that booking is validated and takes precedence over the driver’s current Redis assignment.

Recovery handling was also strengthened so pending driver benefits can be retried independently of driver cleanup. Campaign redemption failures now keep the durable recovery marker active instead of being acknowledged as completed, allowing the reconciler to retry benefit publication safely.

Completed trips now keep route-stop progress synchronized during settlement, and scheduled-booking details remain restricted to the intended driver while preserving the expected pre-acceptance flow for immediate bookings.

The rollout of the normalized booking_stops model was made safer for mixed-version deployments. Legacy pickup and drop-off columns are retained for a compatibility release, new writes keep both representations synchronized, reads can fall back to legacy endpoint data when stop rows are missing, and Redis search state is rebuilt through the same compatibility accessors. A repair migration restores and backfills legacy endpoint columns in environments where they were already removed.

References

Backend containerization, service hardening, and private image registry preparation

We prepared the backend deployment path for container-based builds and future image publishing.

A Zot container registry is now available at registry.xicar.net. This gives the platform a private registry endpoint that can be used by upcoming backend image build and deployment workflows.

The ride-hailing, wallet, and affiliate backends also merged their new production Docker implementations. The updated container setup standardizes the Laravel services around production-ready images, with role-specific runtime targets where applicable and serialized startup migrations to avoid competing schema changes during concurrent container starts.

The ride-hailing backend additionally merged updated development and production environment templates for the wallet and affiliate integrations. The documented contract now includes the required wallet service key and affiliate service settings, while keeping those service credentials backend-only.

Ride-hailing booking and attendant safeguards

Customer-visible driver details are now tied more strictly to the driver actually persisted on a booking. Before acceptance, offer recipients are hidden from the customer, and cached driver metadata is only used when it matches the accepted booking owner. Reassignment also clears stale driver and tracking state so the customer experience follows the latest booking ownership.

The attendant application now requires explicit API and WebSocket runtime configuration instead of silently falling back to defaults. Local setup is consolidated around the example environment contract, reducing the chance that a build points at an unintended backend.

Wallet backend cleanup

The wallet service removed unused Node.js, Vite, and Tailwind scaffolding from its Laravel backend. Development and container workflows are now PHP-only, reducing build dependencies while preserving the existing API routes, JSON status response, health endpoint, and wallet runtime behavior.

Affiliate backend cleanup

The affiliate service removed unused Node.js, Vite, and Tailwind scaffolding from its Laravel backend and replaced the stock browser welcome page with a JSON service-status response. API routes, Swagger support, and the existing health endpoint remain intact while the runtime and development setup no longer depend on unnecessary frontend tooling.

Changelog sharing metadata

The changelog site now ships its own favicon and social-preview image from repository-owned assets. Open Graph and Twitter/X metadata use those local assets so shared changelog links can render a consistent preview without depending on an external avatar image.

References

Driver ratings and ride-service restrictions

Administrative driver rating and ride-service restriction controls are now available end to end, with the matching ride-hailing backend enforcement merged alongside the admin interface work.

Driver ratings and service-level restrictions

The admin interface now shows driver ratings by ride service, including rating source and author attribution, and allows administrators to add ratings tied to either Xiclo two-wheel service or Xicar four-wheel service.

Administrators can also restrict a driver from a specific ride service without disabling the driver’s access to the other service. Restrictions can record a reason and optional supporting rating, and the admin interface supports reinstatement plus review of driver appeals.

Trusted Cloudflare Access identity is forwarded to the backend for these actions so administrative ratings and restriction decisions can be attributed to the authenticated administrator.

The ride-hailing backend now stores the added rating metadata, supports service-specific restriction records and driver appeals, and enforces active restrictions when drivers go online, receive offers, or attempt to accept bookings.

References

Attendant access, booking, and admin workflow improvements

This update brings tighter attendant access controls together with a smoother admin experience for managing day-to-day operations.

Attendant access and registration

Attendant registration now supports explicit pending, active, inactive, and archived account states. New attendants remain in an approval-pending flow until an administrator grants access, while disabled or archived attendants are prevented from continuing service operations.

The attendant app also rechecks account access while it is in use, so administrative changes can take effect without relying on a fresh sign-in. On the backend, duplicate phone checks are normalized, administrative attendant actions are HMAC-protected, and archived attendants retain their historical booking records.

Attendant booking and dashboard workflows

Attendant-created bookings now remain available for matching instead of being automatically cancelled when the normal driver retry budget is exhausted. The app surfaces driver acceptance notifications, keeps active booking status synchronized through WebSocket updates and targeted REST reconciliation, and shows a single completion or cancellation result even when duplicate lifecycle updates arrive.

The attendant home screen now uses a compact dashboard feed for pending, accepted, and trip-started booking counts plus online-driver availability. Booking history shows customer details while withholding assigned-driver information until acceptance, and booking cards expose the booking ID so attendants can match notifications to the correct trip.

Shared WebSocket subscriptions now track ownership per screen, preventing one screen from accidentally disconnecting another screen that is watching the same booking. The backend also batches online-driver session reads to reduce repeated Redis round trips during the dashboard’s periodic refresh.

Admin attendant management

The admin interface now supports editing attendant profiles, enabling or disabling access, archiving accounts, and restoring archived attendants. Booking filters can load the complete attendant list, including archived attendants where historical records need to remain identifiable.

Admin data views also gain clearer loading states, debounced search behavior, client-side sidebar navigation that preserves scroll position, and skeleton placeholders across major dashboard screens.

Scheduling, notifications, and exports

Notification schedules can now be edited, cancelled, and deleted with stronger schedule timing and app validation. Delivery failures are reported with partial fan-out retry details, while status refreshes provide clearer feedback.

Admin date and time rendering is standardized on Manila time, list searches are normalized and debounced, and full booking PDF exports now expose progress and can be cancelled. The admin Docker Compose default database is also updated to xicaradmin.

References

Introducing the Xicar changelog, wallet, and referral foundations

Xicar now has one place to follow meaningful product and operational changes.

Each update pairs what changed with why it matters, giving the team a shared, business-friendly record of progress without losing the technical details needed for traceability.

Infrastructure
Hugo-powered changelog site

The changelog site now runs on Hugo instead of the custom Python static-site generator. The existing design remains intact, while daily Markdown files, automatic date ordering, month grouping, and the static public/ output make ongoing publishing simpler and more consistent.

The migration also adds Hugo-based smoke checks pinned to version 0.147.7, preserving the site’s JavaScript-free output and validation of links, dates, headings, and security-sensitive content. Cloudflare Pages preview validation passed; production deployment status is not separately verified here.

Wallet and referral foundations

The wallet service gained its initial MVP implementation, establishing the foundation for customer and driver wallet operations that later ride-payment work builds on. PayMongo reconciliation was also extended to resolve payments by payment intent and release eligible tips immediately after successful reconciliation.

The Affiliate service introduced referral tracking and commission processing, establishing the first backend path for linking referrals and calculating referral-related commissions before the later cross-service referral flow was integrated.

References

Admin fare controls add service filtering and safer surge validation

The admin fare tools now make service-specific pricing and zone management easier to operate.

Location-discount analytics, location-discount maps, and surge-zone maps can now be filtered by service type, with each view remembering the selected filter. The “All service types” option is handled consistently across the discount and surge-zone flows so administrators can manage rules that apply across both Xiclo and Xicar.

Fare settings also now validate the fallback surge multiplier before saving. Values below 1.0 are rejected with an inline error instead of being silently coerced, while 1.0 remains the supported way to disable fallback surge outside configured zones.

These changes reduce ambiguity when reviewing service-specific fare rules and help prevent invalid fallback surge values from being submitted.

References