🧪 How to Simulate Prepaid Top-Up with Dummy Product (`operatorId` 9990)

This guide explains how to simulate a prepaid mobile top-up using the CSQ API with the dummy product 9990, ideal for safe integration testing. It uses the real methods from the Recharge category and shows how the input and output flow should behave, including dynamic parameter discovery via Get Parameters.

🔁 Recommended Flow for Dummy Recharge

Call Get Parameters

(If dynamic) Call Get Products

Execute Purchase

🔹 Step 1: Discover Required Fields (Get Parameters)

Method
Get Parameters
Use operatorId = 9990 for DummyTopup

Purpose
Returns a list of required fields that must be submitted to perform the recharge. These fields are used to dynamically build the form or request body.

Example Response

{
  "rc": 0,
  "message": "OK",
  "dynamic": false,
  "parameters": [
    {
      "field": "account",
      "labels": {
        "en": "Mobile number",
        "es": "Número de móvil"
      }
    }
  ]
}

✅ In this dummy case, only the field account is required, representing the beneficiary phone number.

🔸 Step 2: Build the Purchase Payload

Method
Purchase

Payload Example

{
  "amountToSendX100": 1000,
  "localDateTime": "2025-07-08T10:00:00Z",
  "account": "600000001" // Ends in '001' → triggers simulated error 971 (Dummy logic)
}

Result Simulation Based on account Suffix

Ends With	Response Outcome
`000`	✅ Success
`001`	❌ Error 971
`002`	❌ Error 990
other	❌ Error 991 (default)

These values let you test different outcome scenarios depending on what account value you submit.

🧪 Notes for Testing

You can safely use real phone-like numbers (e.g. 600000000) to trigger different results.

The dummy product will not send any real request to a mobile operator.

Use the resultcode and resultmessage fields in the response to validate frontend handling.

💶 About `amountToSendX100`

The field amountToSendX100 represents the amount to be sent or paid — expressed in cents, not units. That means:

A value of 100 corresponds to 1.00

A value of 1000 corresponds to 10.00

✅ Accepted Range

You can safely submit any integer value between 100 and 1000, inclusive.

Value	Interpreted As
`100`	1.00
`250`	2.50
`500`	5.00
`1000`	10.00

🛡️ This validation range applies to dummy product flows and ensures safe testing without exceeding preset thresholds.
📌 When integrating real products — as opposed to dummy ones — be sure to use the valid price ranges or denominations supported by each product, in line with the values published in the catalog.
✅ Submitting unsupported or incorrect amounts may result in validation errors or rejected transactions from the provider.
🧾 Tip: Always consult the product catalog or pricing metadata to ensure the amountToSendX100 aligns with available denominations (e.g. €500, €1000, etc.) for the selected operator or voucher.
Make sure your frontend UI reflects this correctly — for example, showing the amount in euros while submitting in cents. Let me know if you'd like helper functions or snippets to convert user-entered values into the correct format 📘✨

🧠 Developer Tips

Always call GET /parameters first to dynamically detect required fields.

When testing multiple error paths, change the suffix of account to force the desired response.

You do not need to call GET /products since dynamic is false for DummyTopup.

📎 Related Documentation:

Recharge Methods Overview

Dummy Product-simulation Guide

Top-Up Simulation

🧪 How to Simulate Prepaid Top-Up with Dummy Product (operatorId 9990)#

🔁 Recommended Flow for Dummy Recharge#

🔹 Step 1: Discover Required Fields (Get Parameters)#

🔸 Step 2: Build the Purchase Payload#

🧪 Notes for Testing#

💶 About amountToSendX100#

✅ Accepted Range#

🧠 Developer Tips#