Status: living document. It must be audited against production before it is published.
This is an English translation of the Spanish original, which is the reference text.
1. Purpose
To keep transparency about third parties that may receive or process information in providing the Service.
Not every provider listed necessarily acts as a subprocessor under the same legal role. Some may be independent controllers or providers contracted directly by the Customer. The role must be validated integration by integration.
2. Providers currently identified
| Provider / category | Function | Potential data | Preliminary role | Status |
|---|---|---|---|---|
| Google Cloud / Firebase | Hosting, databases, functions, authentication, storage | Account, orders, customers, logs | Probable subprocessor | Implemented |
| Meta / WhatsApp | Messaging and events | Phone, messages, IDs, metadata | Third party / role to be validated | Implemented |
| Meta / Instagram | Direct messages, comments and posts of connected professional accounts | Instagram ID and username, messages, comments, posts, token (encrypted) | Third party / role to be validated | In development; available only after Meta's approval |
| Google Maps | Geocoding, distance, maps | Address, location | Subprocessor or third party | Implemented |
| OpenRouter / LLM provider | Language processing | Text needed for understanding | Probable subprocessor | Implemented depending on the flow |
| Yappy / Banco General | Payment | References, status, merchant | Payment provider / independent | Implemented depending on the customer |
| PagueloFácil | Payment | Checkout and transaction data | Payment provider / independent | Integration available |
| NeoPayment / MetroBank | Payment | Checkout and transaction data | Payment provider / independent | Integration available |
| CyberSource | Payment | Checkout and transaction data | Payment provider / independent | Integration available |
| Delivery operator chosen by the Restaurant | Logistics execution | Order, contact, address, location | Independent operator / role to be validated | Depending on use |
| Operator's operational channel | Logistics communication | Minimal operational information | Third party | Depending on use |
| Push/notifications | Notifications | Device token, event | Probable subprocessor | Depending on implementation |
| Domain DNS/hosting | Custom domains | Technical data | Third party | Depending on customer |
| Electronic invoicing PAC | Electronic invoicing | Tax data and invoice | Third party / role to be defined | Future |
3. Fields the public version must have
For each provider:
- legal name;
- service;
- categories of data;
- main processing location when known;
- link to its privacy policy;
- start date;
- end date;
- Actib module that uses it.
4. Onboarding process
Before adding a provider that processes Personal Data:
- Review the need.
- Minimize the data sent.
- Review privacy and security terms.
- Identify country/region.
- Classify the legal role.
- Add to the internal register.
- Notify customers if the DPA requires it.
- Configure secrets and least-privilege access.