MallPlus Open Platform Console
Console Documentation
Getting Started > Sandbox Testing

Sandbox Testing

Last Updated: 2026-07-03

Sandbox Environment

MallPlus provides a fully isolated sandbox environment where you can develop and test your integration without affecting production data. The sandbox mirrors the production API exactly but operates on a separate dataset.

The sandbox uses the same base URL as production:

https://sandbox.open.mallplus.ph/open/v1/

There is no separate sandbox hostname. Sandbox and live requests hit the same host — the environment is decided by which credentials you sign the request with. Your app's sandbox Client ID (prefix mp_) reaches sandbox data; its live Client ID (prefix mp_live_) reaches production. HMAC signing works identically in both.

Test Data

The sandbox comes pre-populated with sample data including test products, orders, sellers, and inventory records. You can also create and manage your own test data through the Sandbox Seller Center or the Test Account and Test Order tools in the console to generate test scenarios quickly.

Note: Sandbox data is reset weekly (every Sunday at 00:00 UTC). Do not rely on persistent test data across weeks.

Sandbox Seller Center

The Sandbox Seller Center is a fully functional merchant interface embedded in the Developer Console at /seller-center. It uses your sandbox shop credentials — the seller ID and password issued when you created a sandbox shop via the Test Account tab — so you can manage test data exactly as a real seller would.

Test Products

Use the Products section of the Sandbox Seller Center to create, edit, and delete test products for your sandbox shop. Each product you create is immediately available through the sandbox Open API at GET https://sandbox.open.mallplus.ph/open/v1/products using a shop-scoped access token.

  • Create a product by providing a title, price, category, and optional image.
  • Copy the product ID from the product list — you'll need it when placing test orders.
  • Edit or delete products at any time; changes reflect instantly in the sandbox API.

My Orders

The My Orders tab shows all test orders placed against your sandbox shop, grouped by status: Unpaid, To Ship, Shipping, Completed, and Return / Refund / Cancel.

Two seller-side actions are available to advance the order lifecycle and trigger webhooks:

  • Arrange Shipment — available on orders in To Ship (READY_TO_SHIP) status. Advances the order to PROCESSED and dispatches an order.updated webhook to your push endpoint, letting you test your shipment-handling logic.
  • Cancel — available on Unpaid and To Ship orders. Cancels the order and dispatches an order.updated webhook, so you can verify your cancellation-handling path end-to-end.
Tip: Use the Test Order tool to simulate the buyer side — place a test order, then switch to My Orders to handle it as the seller and watch the order.updated events arrive at your webhook endpoint.

Sandbox Webhook Delivery

The sandbox lets you validate your webhook integration end-to-end before going live. Webhook push events fire from sandbox state transitions — order status changes, logistics updates, and returns events — and are delivered to your configured push endpoint using the same dispatcher as production. That means identical signing, identical headers, identical retry semantics. Verify your handler once here and it works in production.

A complete round-trip through the sandbox:

  1. Configure your webhook URL pointing at your local dev server or an HTTPS tunnel, and subscribe to the events you care about (e.g. order.created, order.shipped, return.approved).
  2. Seed a fresh sandbox slate via POST /open/v1/sandbox/seed — restores the default seller, buyer, and sample products idempotently.
  3. Place a test order via POST /open/v1/sandbox/orders → the order.created webhook fires to your URL.
  4. Advance the lifecycle with pay-mock (mock payment), your own app's ship-order call (→ order.shipped), and deliver-mock — each transition fires the corresponding event.
  5. Assert your endpoint returned 2xx, the payload eventId is new (not already in your processed-events table), and the expected side effects in your database happened.

Every delivery is recorded in the Push Log — you can inspect the status code, response time, and retry history for each attempt. Failed deliveries are kept for inspection; they are not replayable. Sandbox requests must be signed with your sandbox secret (mp_*); live credentials (mp_live_*) cannot reach the sandbox surface and are rejected with 403 SANDBOX_ONLY.

For the full wire format, signing algorithm, and the complete event catalog, see the Push Mechanism guide.

Pre-GA payloads: Order-event webhook payload shapes are pre-GA and documented as subject to change when the Orders API is released. Do not hardcode business logic against Alpha payloads — treat fields as illustrative and version your parser defensively.

Going Live

When your integration is tested and working in the sandbox, submit the Go Live request from your app detail page before switching any traffic to production. Before doing so, confirm that:

  • Your app is already in Active (Sandbox) status
  • All required scopes have been granted
  • Error handling and retry logic are implemented
  • Webhook endpoints respond reliably within the 30-second timeout
  • You have logging in place to troubleshoot issues in production

The Go Live form asks for your product URL, a short integration description, working test credentials, and screenshots that help validate the end-to-end flow. If no admin acts within 24 hours, the request is auto-approved: your Production Client ID and Production Client Secret are issued and an approval email is sent confirming the app is now Live.

Important: Production credentials are issued only after the Go Live request is approved. Do not point your integration to the production base URL until that credential set is available.