Implement the project according to the instructions and requirements provided in **`guideline.md`** and **`README.md`**. Read both files completely first and follow their existing requirements, structure, naming conventions, and technical constraints.

I want the system to look and feel like a **real-world food ordering and cashless payment platform**, not just a basic prototype.

### Main Goal

Build a realistic food ordering system where customers can:

* Browse available food products
* View food images, descriptions, prices, categories, and availability
* Add items to a cart
* Increase/decrease item quantities
* Remove items from the cart
* Review their order before checkout
* Enter customer/order information
* Select their preferred **cashless payment method**
* Complete a realistic payment flow
* Receive an order confirmation and payment status
* View their order details and transaction information

### Cashless Payment Method

Customer checkout uses the configured Xendit one-time GCash Payments API flow when available or manual GCash receipt submission when configured. Only an Administrator may verify a manual transfer. Do not treat a static/manual QR or receipt as automatic payment verification.

### Payment UI Behavior

For **GCash**:

* Create a server-priced payment request with a unique order reference and redirect the customer through the configured provider flow.
* Confirm payment with authenticated server-side provider lookups and/or validated webhooks; match the business, reference, amount, currency, channel, and successful status.
* Keep the order uncreated and Place Order disabled until the backend confirms payment. Never treat a return URL, screenshot, or customer-supplied reference as proof.
* Do not ask for a GCash PIN, OTP, or payment credentials. A static QR cannot provide transaction-level confirmation.

### Important Security Requirement

Do not fake a provider payment or successful transaction. If provider credentials or approval are unavailable, keep checkout disabled and report the setup blocker.

Never store or expose:

* Full card numbers
* CVV
* Passwords
* OTPs
* GCash PINs

Show that the order is pending administrator verification until an Administrator records the confirmed GCash transfer.

### Checkout Experience

Make the checkout page feel like a real commercial food-ordering website.

Use a clear structure such as:

**1. Order Summary**

* Food items
* Quantity
* Price
* Subtotal
* Delivery/service fee if required
* Total amount

**2. Customer Information**

* Name
* Contact number
* Address/order information as required by the existing project

**3. Payment Method**

* GCash only for customer checkout

**4. Payment Details**

* Display the secure provider payment action and exact amount/reference.

**5. Final Confirmation**

* Display complete order summary
* Display selected payment method
* Display total amount
* "Place Order" / "Pay Now" button

### UI/UX

Make the interface look like a **professional food ordering application**.

Prioritize:

* Clean modern design
* Mobile responsiveness
* Easy navigation
* Clear buttons
* Proper spacing
* Food cards
* Category navigation
* Cart sidebar/page
* Professional checkout page
* Payment-method cards
* Clear success/error messages
* Loading states where appropriate
* Order confirmation page
* Consistent typography and styling

The design should feel inspired by modern food-ordering platforms, while **not copying any specific company's exact branding or UI**.

### Functional Requirements

Do not only create the visual interface. Make the functionality work according to the project's existing architecture.

Make sure:

* Cart functionality works
* Quantities update correctly
* Prices calculate correctly
* Checkout totals are accurate
* Payment method selection works
* Payment forms dynamically change
* Required fields are validated
* Invalid payment information shows appropriate errors
* Verified provider payment creates an order/payment record idempotently
* Order status is displayed correctly
* The user can see their order confirmation
* Existing project functionality is preserved

### Existing Project

Before modifying anything:

1. Read `guideline.md`
2. Read `README.md`
3. Inspect the existing project structure
4. Understand the current database/schema if one exists
5. Understand the existing frontend/backend architecture
6. Reuse existing components and functionality where possible
7. Do not unnecessarily rewrite or delete working code

**Do not remove existing features unless `guideline.md` or `README.md` explicitly requires it.**

If the existing project already has authentication, users, products, orders, inventory, database tables, or admin functionality, integrate the new ordering/payment functionality with them instead of creating duplicate systems.

### Database

If the project uses a database, properly connect the following concepts where appropriate:

* Customers/users
* Products/food items
* Categories
* Cart/order items
* Orders
* Payment method
* Payment status
* Transaction ID
* Order status
* Order date/time

Use the existing database design whenever possible.

### Administrator Side

Use the existing Administrator interface to manage accounts, orders, and payment verification. Customer accounts cannot access Administrator actions.

Administrators should be able to see relevant order information such as:

* Order ID
* Customer
* Ordered items
* Total amount
* Payment method
* Payment status
* Order status
* Order date/time

Allow appropriate order-status updates such as:

**Pending → Paid → Preparing → Ready → Completed**

If the existing project has different statuses, follow the existing `guideline.md` and `README.md` requirements.

### Important Development Rules

* Follow `guideline.md` exactly.
* Follow `README.md` exactly.
* Preserve existing working features.
* Do not create unnecessary duplicate files or systems.
* Do not use fake functionality where actual project functionality is expected.
* Do not hard-code values that should come from the database.
* Keep the code organized and maintainable.
* Use reusable components/functions where appropriate.
* Validate user input.
* Handle errors properly.
* Make the application responsive.
* Make the checkout/payment flow feel realistic.
* Use the provider's Test Mode for development/staging where available; do not use fake success when gateway verification is required.
* Do not expose sensitive payment information.

### Final Verification

After implementation:

1. Check that the project builds/runs successfully.
2. Check for syntax/runtime errors.
3. Test adding food to cart.
4. Test changing quantities.
5. Test removing items.
6. Test checkout.
7. Test each payment-method selection.
8. Test payment validation.
9. Test successful, pending, failed, expired, duplicate, and invalid provider-payment scenarios in Test Mode.
10. Verify order creation.
11. Verify payment status.
12. Verify order confirmation.
13. Verify Administrator access and Customer data isolation.
14. Make sure existing functionality still works.
15. Make sure the UI is responsive on desktop and mobile.

If something in `guideline.md` or `README.md` conflicts with the requested payment functionality, **prioritize the explicit project requirements in those files and adapt the payment feature to fit the project's architecture**.

Do not simply describe what needs to be done. **Actually implement the changes in the project.**