Website & Mobile App Information

One account across future clients

The customer API has a versioned response contract and stores account records centrally. A future phone client should use the same account identifiers and server authorization. Each device signs in separately; the same account does not imply sharing browser cookies between devices. Membership and purchased-value records require their own approved ledger integration and are not activated by this release.

Payments and booking confirmation

A displayed membership price or balance is not a charge authorization. No online supplier booking, payment, credit sale or membership enrollment is enabled. A future GLOBUS payment route requires its own explicit customer confirmation and verified records. Removing the supplier connections does not change existing financial program terms or balances.

Permissions and communication

Future optional device access must be requested at the time it is useful. Contact-list access, precise location, tracking and marketing are not prerequisites for basic browsing or travel support in the proposed design. This website has no push-notification service. Do not rely on it for urgent travel updates.

Promotions and outside services

The proposed annual travel giveaway is separate from membership and purchases; it is not open. The final rules must identify the actual sponsor, eligibility, dates, prize and selection process before entry is enabled. Apple and Google are not sponsors of, or involved in, the proposed GLOBUS giveaway. This sentence is not a substitute for complete Official Rules.

Current limits

Customer registration, email verification, sign-in and recovery, saved plans, agency requests, staff-linked confirmed trips, checklists and private file delivery are implemented in the website source. Hosted email delivery must be configured and checked after installation. Travel Guardian does not provide automated monitoring. Supplier orders, GLOBUS checkout/refunds, membership issuance, insurance issuing and push notifications are not enabled.

Native apps must still be compiled, signed, tested on physical iOS/Android devices, connected to the appropriate approved services and reviewed by the stores. A mobile screen or source tree is not evidence of a successful device build, data-safety review or store approval.

The same membership rules across channels

The revised design offers earned access through VIP and optional payments that become 100% usable purchased Travel Credit, with no planning fee. A single server-validated membership and balance record is required for the website and future iOS/Android apps. Route selection, SP illustrations or a payment-return screen cannot grant live status. These are implementation requirements; the customer account API is implemented; a membership ledger and native apps still require their own implementation.

7. Shared Membership Booking Credit

Use the same server-validated account, terms version and source-specific ledger on the website and future iOS/Android apps. Apply server authorization, atomic reservation, idempotent debits/refunds and accessible account deletion. No app-store approval or live payment service is claimed. The real product and storefront rules determine payment routing; terminology alone does not.

Purchased Travel Credit is displayed in dollars and stored in integer USD cents. Every dollar paid creates the same dollar of credit; optional point-equivalent labels do not create another award. Previously accepted balances and source histories remain protected.

Booking Credit has no expiration date, inactivity fee or anniversary reset under this model. Remaining valid credit can be used without buying another membership after paid service ends. The annual 12-month service term and service limits do not shorten the credit. Ending a program requires lawful fulfillment or settlement; this paragraph is not a promise that any particular supplier product or price remains available forever.