Overview

For every new TripBuilder instance, Nezasa sets up several environments, one of them called Staging, which can be used as a test environment.

Domains

TripBuilder domains generally follow this structure:

my-id has to be replaced by the customer's setup ID. Please remember that your production domains may follow a different pattern above if they were white-labelled. Staging domains, however, are never white-labelled.

Characteristics of the Staging Environment

Availability

Availability is provided at the best effort. There is no SLA related to the staging environment.

Before Nezasa's regular releases, the staging environment may be unavailable due to resetting its database with data from the production database. Also, during release testing days, the staging environment may be restricted or not fully functional due to the deployments of release candidates.

Data

The database of the test system is reset every two weeks. There are no backups.

During a reset, the productive data is cloned, anonymised, and made available in the test system. Itineraries and components (as an example) created or modified in staging cannot be taken over to the productive system. Here is how the data is anonymized:

• Personal Information:
  • Names (First and Last): Replaced with random names from predefined lists.
  • Gender: Randomly assigned as ‘Male’ or ‘Female’.
  • Email Address: Hashed and replaced with a format within the Nezasa domain.
  • Phone Number: Hashed and prefixed with an international code.
  • Passport Information: Including number, issuing country, and expiration date, are hashed or replaced with fixed values (e.g., ‘Portugal’, ‘PT’, expiration date ‘2030-06-03’).
  • Nationality: Replaced with ‘Portugal’ and ‘PT’.
    
    
• Address Information:
  • City, Postal Code, Street: Replaced with fixed values (e.g., city ‘Lisbon’, postal code ‘1700’, street ‘Rua Castilho 44’).
  • Country and Region: Unchanged.
    
    
• User Information:
  • Nezasa Employees and Users with Roles: Excluded from anonymization for operational reasons.
  • Customers: Anonymized by modifying names, emails, address details, and contact numbers.
    
    
• Itinerary Information:
  • PAX Information: Includes contact info, billing, shipping details, and child ages.
  • Anonymization Methods: Similar methods are applied to PAX info as personal information (random names, hashed emails, fixed addresses, etc.).
    
    
• Checkout Information:
  • Remote Address: For audit purposes in payment transactions, addresses are anonymized by replacing them with ‘127.0.0.1’.

Login

The same credentials in your production system can be used for staging.

Emails

Please note that the test environment doesn't send any emails. Instead, emails are logged in a service called mailtrap.io. Maximise customers can request a custom mailtrap.io mailbox to access emails sent by the staging environment.

Live Supply and Bookings

The staging environment connects to the suppliers' test systems. Bookings and cancellations can be performed when suppliers provide a test system. Please be aware that suppliers' test systems may not be entirely stable, and the content may be limited. This is different from supplier to supplier.

Further, suppliers may not provide a test system (only a productive environment), so they won't be available in our test environments.

Online Payments

Our test environment uses the test environments of the payment providers. This means you'll have to use the official test credit cards of the payment provider to simulate a payment flow:

• Payyo
• Datatrans

APIs

All APIs are available in the staging environment accordingly.

Midoco

It's possible to configure separate credentials for Midoco for the staging environment. These different credentials can point to a test setup within Midoco. Usually, in Midoco, that would be a specific organisation unit. It's recommended that you create a dedicated test user in Midoco that only has access to that test unit.