Introduction

This document describes the API to make mobile top ups and buy mobile packages. This API offers a REST service to:

• Get available balance
• Get top up providers
• Make a mobile top up
• Get top up information
• Get history Top Up
• List available providers to buy mobile packages
• List available mobile packages
• Buy a mobile package
• Get a mobile package purchase status
• Get history purchases

Environments

For publishing of these services Tpaga provides two environments:

• Staging environment: https://staging.apiv2.tpaga.co/api/gateway_topup/v1/
• Production environment: Tpaga delivers the production URL after the certification of your integration.

Authentication

cURL Example:

CLIENT_ID="neZi59dZrKaUdblk4LvbB391wuzXlzyc65aaBH8r"
CLIENT_SECRET="Ib5m6r0SqLqolkWM7yQ8aBitVRwypDonVcJ4fYn4gD3qIXIX5b683y3gUio9T8Ukau1QEZYvBnNrjoYWC8V0Z5Oag4XXc7P9ny21LD0D8n40fg3JVHH8mJiJf52sPKwh"
AUTH_STRING=$(echo -n "$CLIENT_ID:$CLIENT_SECRET" | base64 | tr -d '\n')

curl -v --location --request POST 'https://staging.apiv2.tpaga.co/o/token/' \
  --header "Authorization: Basic $AUTH_STRING" \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials'

A successful response returns a JSON object in the following format:

{
  "access_token": "<JWT token>",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope":"read write"
}

An example of a valid request sending the Bearer token:

curl -X GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/merchant/balance' \
  --header 'Authorization: Bearer <JWT token>'

Example to revoke an access token:

curl -X POST 'https://staging.apiv2.tpaga.co/o/revoke_token/' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'token=<JWT token>' \
  --data-urlencode 'client_id=<your-client-id>' \
  --data-urlencode 'client_secret=<your-client-secret>'

This API uses OAuth 2.0 with JWT-based access tokens. Clients must first obtain an access token using the client credentials flow and then include it in subsequent API requests via the Authorization header.

Obtaining an Access Token

Endpoint: /o/token/

HTTP Method: POST

Description: To obtain an access token, send a POST request to the /o/token/ endpoint using HTTP Basic Authentication with your client credentials. Your CLIENT_ID and CLIENT_SECRET must be combined, base64-encoded, and included in the Authorization header.

Request Parameters

Note: Client credentials are provided via the HTTP Basic Authentication header.

Response Parameters

HTTP Responses

Using the Access Token

Include the obtained JWT access token in the Authorization header for subsequent API requests

Token Expiration and Renewal

Access tokens are valid for a limited period (as specified by the expires_in value). We recommend caching your access token and reusing it until it is near expiration. Avoid requesting a new token on every API call. When the token is close to expiring, request a new one to maintain uninterrupted service.

Revoking an Access Token

Endpoint: /o/revoke_token/

HTTP Method: POST

Description: If you need to revoke an access token, send a POST request to the /o/revoke_token/ endpoint.

Request Parameters

Response Parameters

The response body is empty if the token revocation is successful.

HTTP Responses

Environment Considerations

Transaction statuses

Every top up and every mobile package purchase has one of the following statuses. The API always returns them in uppercase.

The following diagram shows how the statuses change:

Integration guidelines

Follow these guidelines when you buy a top up (POST /topup_account) or a mobile package (POST /package_buy).

The following diagram summarizes how to handle the response of a purchase:

Timeouts

We suggest a timeout of 30 seconds for purchase requests.

Status queries

Query the status of a purchase with Get top up information or Get purchase information when the purchase request timed out, failed with an error, or returned a status that is not final.

• Make at most 3 queries, within a window of up to 15 minutes.
• Wait between queries with exponential backoff, and add a random variation (jitter) of ±20 % to each wait.
• If the status is still not final after the last query, stop querying and wait for the reconciliation process, according to the procedure agreed during your onboarding.

For example, query right after the timeout or the error (minute 0), then at minute 5 and at minute 15. These are waits of 5 and 10 minutes.

Idempotency

The idempotency_token identifies each purchase. Use a value that you never reuse, such as a UUID.

• Top ups: if you send a request with an idempotency_token that already exists, the API does not create a new transaction. It answers 409 with the existing transaction: its current status and the data of the original request. Any different data in the new request is ignored. For example, the same idempotency_token with a different amount does not produce a new top up.
• Mobile packages: if you send a purchase with an idempotency_token that already exists, the API answers 422 (field: idempotency_token) and does not create a new transaction. Use Get purchase information to query the status of the original purchase.
• A new idempotency_token is always processed as a new purchase, even if the rest of the data is the same as in a previous purchase.
• After a 422 response, correct the data and send the purchase with a new idempotency_token. However, when the 422 HTTP status is caused by an idempotency_token that already exists, the purchase was already registered, so query its status first. Send a new purchase with a new idempotency_token only if you want an additional purchase or the original one is REJECTED. While the original purchase has a status that is not final, a new purchase (different idempotency_token) can result in two purchases.
• Tpaga does not retry a purchase automatically.

Reversals and cancellations

The API does not offer reversals or cancellations of top ups or mobile package purchases, and there is no channel to request them.

Errors

When a request fails, the response body describes the error.

Validation errors

Example of a validation error (422):

{
    "error_message": "Este campo no puede estar en blanco.",
    "field": "payment_token",
    "value": ""
}

When the response code is 422, the body has these fields:

If several fields are invalid, the response describes only one of them.

Other errors

Example of a 402 response:

{
    "error_message": "You have no funds. Please top up your account and contact our support team to keep operating. Thank you."
}

Other errors, such as 401, 402 and 403, return a body with only the error_message field.

Example of a 500 response:

{
    "error_message": "Unknown error",
    "error_token": "error-7xk2m9q4w1z8c3v6b0n5h2j4rt"
}

An unexpected error (500) returns error_message with the value Unknown error, and an error_token field.

Top up services

1. Get available balance
2. Get top up providers
3. Make a mobile top up
4. Get top up information
5. Get history Top Up
6. Testing

Get available balance

Endpoint: /merchant/balance

HTTP Method: GET

Description: This service returns the available balance and the maximum loan amount.

Example request:

curl -X GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/merchant/balance' \
  --header 'Authorization: Bearer <JWT token>'

Example response:

{
  "balance": 0,
  "max_loan_amount": 0
}

Request parameters

This endpoint does not need extra parameters to be sent in the request.

Response parameters

HTTP responses

Get top up providers

Example Request:

curl -X GET \
 https://staging.apiv2.tpaga.co/api/gateway_topup/v1/service_providers \
 -H 'Authorization: Bearer <JWT token>'

Example Response:

{
    "service_providers": [
        {
            "slug": "movistar",
            "name": "Movistar",
            "icon_url": "https://some-icon-url.com"
        },
        {
            "slug": "claro-movil",
            "name": "Claro Móvil",
            "icon_url": "https://some-icon-url.com"
        },
        {
            "slug": "avantel",
            "name": "Avantel",
            "icon_url": "https://some-icon-url.com"
        },
        {
            "slug": "uff-movil",
            "name": "Uff Móvil",
            "icon_url": "https://some-icon-url.com"
        },
        {
            "slug": "etb",
            "name": "ETB",
            "icon_url": "https://some-icon-url.com"
        },
        {
            "slug": "tigo",
            "name": "Tigo",
            "icon_url": "https://some-icon-url.com"
        }
    ]
}

Endpoint: /service_providers

HTTP Method: GET

Description: This service returns the current available providers.

Request parameters

This endpoint does not need extra parameters to be sent in the request.

Response parameters

Make a mobile top up

Endpoint: /topup_account

HTTP Method: POST

Description: This service tops up the given phone number.

Example request:

curl -X POST \
 https://staging.apiv2.tpaga.co/api/gateway_topup/v1/topup_account \
 -H 'Authorization: Bearer <JWT token>' \
 -H 'Content-Type: application/json' \
 -d '{
    "idempotency_token": "85ab25a1-6389-4737-b91b-0f7ddbc73e9a",
    "amount": 1000,
    "service_provider": "etb",
    "destination_number": "3110001111",
    "payment_token": "wallet-11233dafd",
    "payment_origin": "My company"
 }'

Example response:

{
    "token": "topup-4n8c2x7q1m5z9v3b6k0j2h8wdr",
    "idempotency_token": "85ab25a1-6389-4737-b91b-0f7ddbc73e9a",
    "destination_number": "3110001111",
    "service_provider": "etb",
    "amount": 1000,
    "payment_token": "wallet-11233dafd",
    "payment_origin": "My company",
    "route": "PUNTORED",
    "external_gateway_auth_code": "526268936",
    "gateway_topup_token": "ppr-9t3k7m1x5c8v2b6n0q4z7j1h5w3d",
    "status": "AUTHORIZED",
    "result_code": 0
}

Request parameters

If destination_number does not have 10 or 12 digits, the API answers 422 with field: mobile_number. The transaction is registered as REJECTED, so its idempotency_token cannot be used again: send the corrected purchase with a new idempotency_token.

Response parameters

HTTP responses

Error Details

When the response code is 422, the body follows the format described in Validation errors. A repeated idempotency_token is not a validation error in top ups: see Idempotency.

Example Errors

Get top up information

Endpoint: /topup_account/

HTTP Method: GET

Description: This service returns a top up transaction.

Example request:

curl --location --request GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/topup_account/85ab25a1-6389-4737-b91b-0f7ddbc73e9a' \
  --header 'Authorization: Bearer <JWT token>' \
  --header 'Content-Type: application/json'

Example response:

{
    "token": "topup-4n8c2x7q1m5z9v3b6k0j2h8wdr",
    "idempotency_token": "85ab25a1-6389-4737-b91b-0f7ddbc73e9a",
    "destination_number": "3110001111",
    "service_provider": "etb",
    "amount": 1000,
    "payment_token": "wallet-11233dafd",
    "payment_origin": "My company",
    "route": "PUNTORED",
    "external_gateway_auth_code": "526268936",
    "gateway_topup_token": "ppr-9t3k7m1x5c8v2b6n0q4z7j1h5w3d",
    "status": "AUTHORIZED",
    "result_code": 0
}

Request parameters

Response parameters

HTTP responses

Get history Top Up

Endpoint: /topup_account/transactions

HTTP Method: GET

Description: This endpoint returns the history of top ups made by a client of the API. It supports paginated queries and date range filtering.

Example request:

curl --location --request GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/topup_account/transactions?page=1&per_page=50&start_date=2026-10-01&end_date=2026-10-31' \
  --header 'Authorization: Bearer <JWT token>' \
  --header 'Content-Type: application/json'

Example response:

{
    "count": 3,
    "transactions": [
        {
            "idempotency_token": "85ab25a1-6389-4737-b91b-0f7ddbc73e9a",
            "destination_number": "3110001111",
            "payment_origin": "My company",
            "service_provider": "etb",
            "amount": 1000,
            "status": "AUTHORIZED",
            "date_created": "2026-10-29 09:20:29"
        },
        {
            "idempotency_token": "f5bbcc29-bd7e-404f-b732-a99a1eee5dd1",
            "destination_number": "3110005555",
            "payment_origin": "My company",
            "service_provider": "claro-movil",
            "amount": 2000,
            "status": "REJECTED",
            "date_created": "2026-10-29 10:05:12"
        },
        {
            "idempotency_token": "324b2346-c01f-4b41-ab8f-4cc6fe8590de",
            "destination_number": "3110002222",
            "payment_origin": "My company",
            "service_provider": "movistar",
            "amount": 5000,
            "status": "UNKNOWN",
            "date_created": "2026-10-30 14:48:03"
        }
    ]
}

Request parameters

Use page and per_page to paginate the results. Transactions are sorted by creation date, from the oldest to the newest.

Use start_date and end_date to filter by creation date. Both dates are in Colombia time (UTC-5), and both are included: the range goes from 00:00:00 of start_date to the end of end_date. If you send one of them, the other is required. start_date cannot be later than end_date.

Response parameters

HTTP responses

Testing

The API offers test phone numbers to assist you in the development and certification process. Send the following phone numbers in your requests to simulate different scenarios. These numbers only work in the staging environment.

Mobile packages services

1. Get mobile package providers
2. Get mobile packages
3. Purchase a mobile package
4. Get purchase information
5. Get history purchases
6. Test data

Get mobile package providers

Endpoint: /mobile_package_service_providers_list

HTTP Method: GET

Description: This service returns the mobile package providers that are currently available for purchases. Only enabled providers are listed.

Example request:

curl -X GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/mobile_package_service_providers_list' \
  --header 'Authorization: Bearer <JWT token>'

Example response:

{
    "service_providers": [
        {
            "name": "TIGO",
            "provider_code": "3",
            "operator_logo_url": "https://storage.googleapis.com/bucket-faas/suppliers/3.webp",
            "enabled": true
        },
        {
            "name": "CLARO PAQUETES",
            "provider_code": "58",
            "operator_logo_url": "https://storage.googleapis.com/bucket-faas/suppliers/58.webp",
            "enabled": true
        },
        {
            "name": "VIRGIN MOBILE PAQUETES",
            "provider_code": "72",
            "operator_logo_url": "https://storage.googleapis.com/bucket-faas/suppliers/72.webp",
            "enabled": true
        },
        {
            "name": "MOVISTAR PAQUETES",
            "provider_code": "30",
            "operator_logo_url": "https://storage.googleapis.com/bucket-faas/suppliers/30.webp",
            "enabled": true
        }
    ]
}

Request parameters

Use page and per_page to paginate the results. The list has no defined order, so when you paginate, a provider can appear on more than one page or be missing. To get the complete list, request it in a single page, with a per_page value of 200.

Response parameters

HTTP responses

Get mobile packages

Endpoint: /packages

HTTP Method: GET

Description: This endpoint returns the mobile packages currently available for purchase. It can return all the current mobile packages, or only the packages of a specific service provider.

Example request:

curl --location --request GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/packages' \
  --header 'Authorization: Bearer <JWT token>' \
  --header 'Content-Type: application/json'

Example request with specific service provider:

curl --location --request GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/packages?provider_identifier=58' \
  --header 'Authorization: Bearer <JWT token>' \
  --header 'Content-Type: application/json'

Example response:

{
    "packages": [
        {
            "name": "200 MINUTOS A TODO OPERADOR",
            "description": "200 MNTS O 20DIAS",
            "amount": 9900,
            "validity": "20 DÍAS",
            "package_code": "024",
            "sku": "50015",
            "category_code": "9",
            "category_description": "HABLAR",
            "provider_code": "58"
        },
        {
            "name": "18 MINUTOS A VENEZUELA - $5.000",
            "description": "18MIN_A_VNZLA-30D",
            "amount": 5000,
            "validity": "30 DÍAS",
            "package_code": "353",
            "sku": "50050",
            "category_code": "9",
            "category_description": "HABLAR",
            "provider_code": "58"
        },
        {
            "name": "1.5 GB DE NAVEGACION + MUNUTOS Y MENSAJES ILIMI. + REDES SOCIALES (WHATSAPP FACEBOOK TWITTER) + 7 DIAS POR $7.500",
            "description": "1.5GB_MIN ILIMT+7D",
            "amount": 7500,
            "validity": "7 DIAS",
            "package_code": "767",
            "sku": "50130",
            "category_code": "7",
            "category_description": "TODO INCLUIDO",
            "provider_code": "58"
        },
        {
            "name": "TODO INCLUIDO CON MINUTOS ILIMITADOS CHAT DE WHATSAPP FACEBOOK Y TWITTER  12GB POR 30 DIAS",
            "description": "12GB/ILIMITADO_30D",
            "amount": 41000,
            "validity": "30 DIAS",
            "package_code": "939",
            "sku": "50148",
            "category_code": "7",
            "category_description": "TODO INCLUIDO",
            "provider_code": "58"
        }
    ]
}

Request parameters

Use provider_identifier to get only the packages of one service provider.

Use page and per_page to paginate the results. Packages are sorted by category, but packages of the same category have no defined order, so when you paginate, a package can appear on more than one page or be missing. To get the complete list, request it in a single page, with a per_page value of 200.

Response parameters

HTTP responses

Purchase a mobile package

Endpoint: /package_buy

HTTP Method: POST

Description: This service allows the client to buy a mobile package.

Example request:

curl --location --request POST 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/package_buy' \
 --header 'Authorization: Bearer <JWT token>' \
 --header 'Content-Type: application/json' \
 --data-raw '{
     "destination_number": "3110001111",
     "provider_code": "58",
     "amount": 7500,
     "idempotency_token": "8aefa051-1383-4d23-bb5c-55d5584746ab",
     "payment_token": "wallet-11233dafd",
     "package_code": "767"
 }'

Example response:

{
    "idempotency_token": "8aefa051-1383-4d23-bb5c-55d5584746ab",
    "destination_number": "3110001111",
    "amount": 7500,
    "payment_token": "wallet-11233dafd",
    "package_code": "767",
    "provider_code": "58",
    "route": "PUNTORED",
    "external_gateway_auth_code": "526268936",
    "status": "AUTHORIZED",
    "result_code": 0
}

Request parameters

If destination_number is not a valid mobile number, the API answers 422 with field: mobile_number. The transaction is registered as REJECTED, so its idempotency_token cannot be used again: send the corrected purchase with a new idempotency_token.

Response parameters

HTTP responses

Error Details

When the response code is 422, the body follows the format described in Validation errors.

Example Errors

Get purchase information

Endpoint: /package_buy/

HTTP Method: GET

Description: This service returns a mobile package purchase transaction.

Example request:

curl --location --request GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/package_buy/8aefa051-1383-4d23-bb5c-55d5584746ab' \
  --header 'Authorization: Bearer <JWT token>' \
  --header 'Content-Type: application/json'

Example response:

{
    "idempotency_token": "8aefa051-1383-4d23-bb5c-55d5584746ab",
    "destination_number": "3110001111",
    "amount": 7500,
    "payment_token": "wallet-11233dafd",
    "package_code": "767",
    "provider_code": "58",
    "route": "PUNTORED",
    "external_gateway_auth_code": "526268936",
    "status": "AUTHORIZED",
    "result_code": 0
}

Request parameters

Response parameters

HTTP responses

Get history purchases

Endpoint: /package_buy/transactions

HTTP Method: GET

Description: This endpoint returns the purchase history of packages made by a client of the API. It supports paginated queries and date range filtering.

Example request:

curl --location --request GET 'https://staging.apiv2.tpaga.co/api/gateway_topup/v1/package_buy/transactions?page=1&per_page=50&start_date=2026-10-01&end_date=2026-10-31' \
  --header 'Authorization: Bearer <JWT token>' \
  --header 'Content-Type: application/json'

Example response:

{
    "count": 3,
    "transactions": [
        {
            "idempotency_token": "8aefa051-1383-4d23-bb5c-55d5584746ab",
            "destination_number": "3110001111",
            "amount": 7500,
            "package_code": "767",
            "provider_code": "58",
            "status": "AUTHORIZED",
            "created_at": "2026-10-29 11:20:02"
        },
        {
            "idempotency_token": "bc2cee0c-b1f2-4033-b02f-cc07fa4d8c00",
            "destination_number": "3110000000",
            "amount": 9900,
            "package_code": "024",
            "provider_code": "58",
            "status": "REJECTED",
            "created_at": "2026-10-29 16:42:37"
        },
        {
            "idempotency_token": "0084ee14-27b8-452c-a886-8f4ceb57270d",
            "destination_number": "3110006666",
            "amount": 5000,
            "package_code": "353",
            "provider_code": "58",
            "status": "UNKNOWN",
            "created_at": "2026-10-30 08:15:44"
        }
    ]
}

Request parameters

Use page and per_page to paginate the results. Transactions are sorted by creation date, from the oldest to the newest.

Use start_date and end_date to filter by creation date. Both dates are in Colombia time (UTC-5), and both are included: the range goes from 00:00:00 of start_date to the end of end_date. If you send one of them, the other is required. start_date cannot be later than end_date.

Response parameters

HTTP responses

Test data

Because third-party providers sometimes have problems with test environments, the API offers test phone numbers to assist in the development and certification process. These numbers only work in the staging environment.

Changelog

This changelog starts at version 1.1.0. Changes made before that version are not listed.

1.1.0 — 2026-11-06

All the changes in this version are backward compatible. The API itself did not change: this version updates the documentation to describe the current behavior of the API.

Added

• Integration guidelines: suggested timeout, status queries, idempotency, and reversals and cancellations.
• Errors: the format of error responses, common to both services.
• A response example for Make a mobile top up, and query parameters in the examples of both history services.
• Two diagrams: the purchase and status query flow, in Integration guidelines, and the transaction statuses, in Transaction statuses.
• The page and per_page parameters of Get mobile package providers, which were missing in the documentation.

Clarified

• Transaction statuses: a single section for top ups and mobile packages. It lists the statuses in uppercase, as the API returns them, and states which statuses are final.
• UNKNOWN, IN_PROGRESS and CREATED are not final statuses. Do not treat them as declined. After the status query window, wait for the reconciliation process, according to the procedure agreed during your onboarding.
• A purchase request that timed out must never be treated as declined or failed.
• A repeated idempotency_token is answered differently by each service: top ups answer 409 with the existing transaction, and mobile packages answer 422.
• Use an idempotency_token that you never reuse, such as a UUID.
• A new idempotency_token is always processed as a new purchase, even with the same data. This replaces the statement that the token lets you "retry transactions safely".
• The API does not offer reversals or cancellations.
• A 422 response describes only one invalid field, and it includes value only when that field is part of the request body.
• In top ups, destination_number must have 10 or 12 digits. For DirecTV, it is the DirecTV account number: only digits, up to 12. An invalid number is answered with 422 and field: mobile_number, and its idempotency_token cannot be used again.
• The maximum length of idempotency_token, payment_origin and payment_token.
• amount is an integer in Colombian pesos (COP), without decimals. The minimum and maximum amounts are configured for each client. Top up amounts must be multiples of 100.
• History services: dates and the start_date and end_date filters are in Colombia time (UTC-5), both days of the range are included, and transactions are sorted from the oldest to the newest.
• HTTP responses of Make a mobile top up and Purchase a mobile package: 200 means that the request was processed, so check status (only AUTHORIZED means success); 500 means an unexpected error: query the status; a new idempotency_token is treated as a new purchase attempt; 502 means UNKNOWN; 503 means REJECTED when the body contains the transaction, or an account that is not properly configured when it does not.
• 402 is returned only when your available funds (balance plus credit limit) are already exhausted.
• Get available balance answers 503 when your account is not properly configured.
• Get mobile package providers lists only enabled providers, and the list has no defined order.
• Get mobile packages sorts the packages by category. Packages of the same category have no defined order.
• provider_code and package_code are strings in package purchases. The documentation previously declared them as integers. For backward compatibility, the API still accepts integers, but sending strings will be mandatory in an upcoming API version. If you are building a new integration, use strings.

Fixed

• The top up statuses were listed in lowercase (authorized, rejected, unknown, created, in_progress). The API returns them in uppercase.
• The mobile package description of IN_PROGRESS said that this status is returned only when two concurrent requests are received.
• The top up error examples listed a 422 for an idempotency_token that already exists. Top ups answer 409 in that case (see Idempotency).
• error_message and field were listed as fields of successful responses. They are only part of error responses.
• The maximum lengths of payment_origin (64) and payment_token (255) were swapped in Make a mobile top up.
• In the mobile package error examples, a disabled package is reported in the provider_code field, not in package_code.
• result_code was documented as a non-nullable String in Make a mobile top up. It is a nullable Integer.
• packages -> provider_code was documented as Integer in Get mobile packages. It is a String.
• In Get history Top Up, the date field is date_created, not created_at.
• In both history services, the date format is YYYY-MM-DD HH:MM:SS, not AAAA-MM-DD HH-MM-SS.
• The 500 response of the purchase services was described as safe to retry. Retrying with a new idempotency_token can result in two purchases.
• Get purchase information answers 200 for any existing purchase, whatever its status. It does not answer 502 or 503.
• Examples: the idempotency_token did not match between the request and the response of Purchase a mobile package, nor between the URL and the body of Get top up information.
• The example of Get top up information used None instead of null, included a date_created field that this service does not return, and showed an outdated route value.
• The history examples used phone numbers that are not valid, repeated an idempotency_token, and in mobile packages, count did not match the number of transactions.
• The example request of Purchase a mobile package sent provider_code and package_code as numbers. It now sends them as strings.
• In the mobile package test data, the HTTP codes of 3110006666 (UNKNOWN, 502) and 3110000000 (REJECTED, 503) were swapped.
• The cURL example to obtain an access token was missing --request, so curl treated POST as an additional URL.
• Typos, the indexes of both services (wrong numbering and broken links), duplicated headings and several descriptions.
• In Get top up information, the descriptions of route, external_gateway_auth_code and gateway_topup_token referred to mobile packages.

Removed

• The production URL. Tpaga delivers it after the certification of your integration. The URL did not change, so integrations already in production do not need to do anything.
• The instruction to contact Tpaga's support for IN_PROGRESS, UNKNOWN and CREATED transactions. Instead, wait for the reconciliation process, according to the procedure agreed during your onboarding.
• payment_origin from the mobile package error examples. Package purchases do not use this field.
• The test value 3110003333 (top ups). We suggest not using it in test, QA or certification environments. Tpaga will mark this value as deprecated in a later version and will publish new values to simulate more test scenarios.
• The test value 3110007777 (mobile packages). We suggest not using it in test, QA or certification environments. Tpaga will mark this value as deprecated in a later version and will publish new values to simulate more test scenarios.