Third-party integrations
Managed platform providers
| Provider | Purpose | Information handled |
|---|---|---|
| Cloudflare Pages | Frontend build, deployment, static hosting, edge delivery, and rollback capability | Static release artifacts, build inputs, deployment metadata, and logs |
| Supabase | PostgreSQL, authentication, data APIs, realtime, object storage, serverless workflows, scheduling, and backend logs | Application identities, customer and policy records, workflow and finance information, documents, and service metadata |
| Sentry | Error tracking, performance traces, session replay, logging, and release diagnostics | Configured diagnostic context, performance data, replay samples, release metadata, and source maps |
Business and communication providers
| Provider | FinTrack use | Information exchanged |
|---|---|---|
| Gallabox / WhatsApp | Contact handling, templates, messages, delivery status, and inbound events | Phone number, message fields, provider references, and delivery or response status |
| VoiceIQ | Assisted outbound calls, status, recordings, transcripts, and call analysis | Phone number, approved customer or vehicle context, call reference, recording location, and analysis result |
| GOOD / Coverstack | Authenticated insurance quote handoff | Customer mobile number and vehicle registration information required for the quote flow |
| Razorpay | Payment-link creation and payment event processing | Customer or transaction references, amount, payment metadata, method, status, and timestamps |
| Credit Mantri | Credit product enrolment, activation, and partner status workflows | Customer and product details, payment confirmation context, and encrypted partner payloads |
| Brevo | Operational report email delivery | Approved recipients, message content, and generated report attachment |
Browser-direct services
| Service | Use | Information leaving the browser | Review note |
|---|---|---|---|
| QuickChart | QR-image generation | Encoded payment payload in a request URL | Browser, proxy, and provider logs receive the request URL |
| jsDelivr | Client-side document-processing runtime delivery | Normal asset-request metadata | Availability and supply-chain integrity depend on the external CDN |
| WhatsApp links | User-initiated conversation handoff | Destination number and any prefilled text | The user leaves FinTrack and becomes subject to WhatsApp controls |
| Unsplash | Authentication-screen image delivery | Normal image-request metadata | Local replacement is not implemented |
Integration controls observed
- Long-lived business-provider credentials are held in trusted server configuration and are not intentionally exposed in the browser application.
- User-initiated serverless calls use managed-session verification where applicable.
- Provider-initiated callbacks use a provider-specific shared-secret or signature check before trusted processing.
- Provider payloads are normalised before persistence, and business confirmation is kept distinct from provider-only status where the workflow requires it.
- Telemetry minimisation, replay masking, retention, and lawful-basis controls require periodic account-level verification.
Integration security contract
Every server-mediated integration is evaluated through the following technical contract:
| Control | Required behavior |
|---|---|
| Authentication | Outbound calls use the provider-supported credential or signature mechanism from trusted configuration; browser code does not receive long-lived provider secrets |
| Authorization | The authenticated actor and tenant can initiate only the provider operation allowed for the current business object and workflow state |
| Data minimisation | The request contains only fields required by the provider operation; logs and telemetry use redacted or derived values where raw personal data is unnecessary |
| Transport | Production requests use TLS with normal certificate validation; insecure downgrade and arbitrary destinations are rejected |
| Validation | Provider responses are parsed into the defined schema, bounded in size, and treated as untrusted input until normalized |
| Callback verification | Provider-initiated requests require a signature, shared-secret, or equivalent provider-specific authenticity check before business state changes |
| Replay and idempotency | Repeated callbacks or retries resolve against a correlation key and current business state so they do not create duplicate payments, messages, or policy effects |
| Timeout and retry | Network calls use bounded timeouts; retries apply only when the operation is safe or idempotent and use a capped schedule |
| State separation | Provider acceptance, delivery, payment, or analysis status is stored separately from FinTrack business approval or completion |
| Observability | Correlation, provider result, duration, and error class are retained without logging credentials or unnecessary payloads |
Provider failure-state model
| State | Meaning | Permitted transition |
|---|---|---|
| Requested | FinTrack accepted an authorised request but has not received a provider result | Send once with a correlation reference |
| Provider accepted | The provider acknowledged receipt but final business outcome is pending | Poll or await a verified callback according to provider design |
| Completed | Provider outcome and required FinTrack business validation succeeded | Record the terminal evidence and suppress duplicate processing |
| Rejected | Provider or FinTrack validation rejected the operation | Present an actionable business error and require corrected input or approval |
| Indeterminate | Timeout or ambiguous response means the external side effect is unknown | Reconcile provider status before retrying a non-idempotent operation |
| Cancelled or reversed | A completed or pending provider effect was explicitly cancelled, expired, refunded, or reversed | Retain both original and reversal evidence; do not delete the history |
Ownership and refresh procedure
- Review browser destinations, application dependencies, server-side provider destinations, and active integrations before each external assessment.
- Confirm provider owner, contract, account status, data-processing terms, region, retained fields, retention, credential rotation, breach contact, and exit procedure.
- Add providers configured only through accounts, DNS, no-code automation, or manual operations, which cannot be established from application evidence alone.
- Maintain the contractual processor register under checklist item 33.
Evidence basis and limitations
The inventory is based on application behavior, internal integration documentation, and a read-only managed-backend deployment review. A deployed integration does not prove that its subscription, credentials, webhook, or most recent transaction is healthy. Contracting entity, region, retention, and data-processing obligations require business confirmation.