Skip to main content
TMT Platform is a serverless backend deployed entirely as Firebase Cloud Functions (v2). It uses two databases for different workloads, Firebase Authentication for identity, and a set of third-party APIs for payments, seating, and billing.

Compute layer

All business logic runs as functions.https.onRequest handlers exported from index.js. There are no long-running servers. Every function is stateless — it reads from databases and external APIs, performs its operation, and returns a response. Functions are written for Node.js 22 and deployed to Google Cloud via the Firebase CLI:
firebase deploy --only functions
The platform exports over 90 named functions from a single index.js entry point, organized into logical modules:
ModuleDescription
exchange_ratesFetch and store BCV exchange rates (USD, EUR vs. Bolívar)
create_client, create_collaborator, create_staffUser registration by role
validate_user_*, setSessionIdAuthentication and session validation
tickets_generate, tickets_list_*, tickets_lock, tickets_unlockTicket lifecycle management
order_created, order_process, order_update, order_payoutOrder creation and fulfillment
transactions_generate, transactions_validateTransaction recording and validation
conciliation_*Financial reconciliation against bank records
money_distribution, total_sales, sold_by_office, number_tickets_soldAnalytics and indicators
*_seatsioSeats.io chart and seat management
stripe_*Stripe payment intents and webhook handling
api_mercantil_*Banco Mercantil debit, credit, and Pago Móvil payments
conciliation_bdv, mobile_payment_bcvBanco de Venezuela reconciliation and mobile payments
billing_emision, generateBillingFromExpensesTFHKA digital invoice generation
offline_office_*Offline ticket office synchronization
app_*Mobile app user-facing functions

Databases

TMT Platform uses two databases with distinct responsibilities.

Firestore (real-time operational data)

Firestore is the primary database for all event-driven, real-time data. It stores:
  • Usersu_clients, u_collaborators, u_staff collections, keyed by Firebase Auth UID
  • Events and tickets — event metadata, ticket inventory, zone assignments
  • Orders — order documents that trigger downstream Cloud Functions via Firestore listeners (onDocumentCreated, onDocumentUpdated)
  • Exchange rates — current and historical BCV rates in data/exchange_rates
  • Notifications and sessions — push notification records and session tokens
Firestore is initialized in config/config.js:
const admin = require("firebase-admin");
admin.initializeApp();
const db = admin.firestore();

PostgreSQL via Cloud SQL (financial records)

PostgreSQL handles structured financial data that requires relational queries, joins, and aggregations — workloads that are impractical in a document store. It stores:
  • Transaction records for reconciliation
  • Bank statement data loaded from Banco Mercantil and BDV
  • Conciliation summaries and adjustment records
  • Billing and invoice data
The config/dbpostgres.js helper connects using the @google-cloud/cloud-sql-connector and exposes a generic sqltmt function that builds and executes SELECT, INSERT, UPDATE, and DELETE queries:
const { sqltmt } = require('../../config/dbpostgres');

// Example: select transaction records
const rows = await sqltmt(
  'select',
  'transactions',
  '*',
  `order_id = '${orderId}'`
);
Each call to sqltmt opens a new connection pool and closes it when the query completes. This is appropriate for serverless execution where functions are short-lived and connection reuse across invocations is not guaranteed.

Authentication

Firebase Authentication manages all user identities. The platform creates Firebase Auth users programmatically during registration:
await auth.createUser({
  email: request.body.data.email,
  password: request.body.data.password,
});
The resulting UID is used as the document key in Firestore (u_clients/{uid}, u_staff/{uid}, etc.), tying the identity record to its Firebase Auth account. Session validation and user type checks are handled by the validate_user_* and setSessionId functions.

Request and response pattern

All HTTP-triggered functions follow a consistent structure:
  • CORS — enabled via the cors package with origin: "*" for cross-origin web clients
  • Request body — payloads are wrapped in a data key: { "data": { ... } }
  • Response — always a JSON object with message, status, and data fields
// Request body structure
{
  "data": {
    "email": "[email protected]",
    "name": "Jane Doe",
    "phone": "+58 412 555 0100"
  }
}

// Response structure
{
  "message": "Ingresado con el ID: abc123",
  "status": 200,
  "data": { "uid": "abc123" }
}
The exchange_rates and a small number of data-fetch functions use a simpler { result: "..." } response and do not require a request body.

Third-party integrations

Stripe

International card payments. Functions: stripe_create_payment_intent, stripe_confirm_payment, stripe_get_payment_intent, stripe_webhook. Uses the official stripe Node.js SDK (v19).

Banco Mercantil

Venezuelan domestic bank payments via the Mercantil API. Supports debit card (api_mercantil_tdd_pay), credit card (api_mercantil_tdc_pay), and Pago Móvil C2P (api_mercantil_c2p_pay, api_mercantil_c2p_auth, api_mercantil_c2p_search).

BCV / Banco de Venezuela

Exchange rate scraping from the BCV website (exchange_rates), mobile payment processing (mobile_payment_bcv), and bank statement reconciliation (conciliation_bdv).

Seats.io

Interactive seating chart management. Functions cover chart publishing, object listing, tag management, seat holds (hold_seats_seatsio), releases (release_seats_seatsio), and bookings (book_seats_seatsio). Uses the seatsio SDK (v87).

TFHKA

Venezuelan digital billing (facturación electrónica). Functions: billing_emision and generateBillingFromExpenses generate TFHKA-compliant electronic invoices from order data.

Firebase Cloud Messaging

Push notifications sent to mobile app users via send_notifications. Notification records are stored in Firestore and listed with list_notifications.

Function categories

User management

Three user roles exist in the platform — clients (event organizers), collaborators (staff attached to a client), and staff (platform administrators). Each role has its own Firestore collection and registration function. The validate_user_platform and validate_user_type functions determine which role a user belongs to at login.

Events and tickets

Tickets are generated in bulk per event zone. The ticket lifecycle includes: generation, locking (reserving for a session), unlocking (releasing), sales assignment, and access control scanning. Both online (tickets_lock, tickets_unlock) and offline office modes (offline_office_tickets, offline_office_tickets_synchronization) are supported.

Orders and transactions

Orders are the central financial document. When an order document is created in Firestore, the order_created trigger fires. Subsequent updates drive processing (order_process), payout splitting (split_payout), and billing (process_order_billing). The transactions_generate function records individual payment transactions linked to each order.

Financial reconciliation

The conciliation module matches TMT transaction records against bank statement files from Mercantil and BDV. The conciliation_process function performs automated matching; conciliation_load_cia_manual and conciliation_load_bank_manual allow manual data loading. Results are summarized with conciliation_summary.

Analytics and indicators

A set of indicator functions query Firestore and PostgreSQL to produce dashboards for event organizers and platform administrators:
  • money_distribution — revenue breakdown by currency and payment method
  • total_sales / total_sales_client — aggregate sales figures
  • sold_by_office — sales performance by ticket office
  • number_tickets_vs_sold — ticket inventory vs. sales ratio
  • offices_vs_offices_active — active vs. total office count
  • general_platform_data — platform-wide summary statistics

Deployment topology

Client (web / mobile app)

        │  HTTPS

Firebase Cloud Functions (Node.js 22)

        ├──▶ Firestore (real-time operational data)
        ├──▶ Cloud SQL / PostgreSQL (financial records)
        ├──▶ Firebase Auth (user identity)
        ├──▶ Stripe API (international payments)
        ├──▶ Banco Mercantil API (domestic payments)
        ├──▶ BCV / BDV (exchange rates, mobile payments)
        ├──▶ Seats.io API (seating charts)
        ├──▶ TFHKA API (digital billing)
        └──▶ Firebase Cloud Messaging (push notifications)
All functions are stateless. Shared state lives exclusively in Firestore, PostgreSQL, or external service APIs. This means each function invocation is independent and the platform scales horizontally without configuration.

Build docs developers (and LLMs) love