FEL Provider Matrix

Source-backed status matrix for FEL/SAT provider adapters in apps/backend/src/fel/.

Use this page to distinguish three different concepts:

• SAT registry rows in fel_certifier
• certifiers merchants can select in billing settings
• provider adapters registered in backend code

---

Runtime matrix

Provider key	Registered adapter	Merchant-selectable certifier?	Direct path payload	RPA path payload	Cancellation behavior
digifact	ProviderDigifactService	Yes	XML sent to Digifact API URL	DTE JSON sent through rpafelapi; certifier fields still identify Digifact	Direct path certifies an ANULACION document; RPA path calls voidCertificate
infile	ProviderInfileService	No	Adapter exists, but direct API URL resolution currently returns empty	DTE JSON can identify Infile if RPA mapping and credentials are valid	Not merchant-selectable until integration allowlist and URL behavior are updated
rpafelapi	ProviderRpaFelApiService	No	Not a direct SAT certifier	Receives DTE JSON serialized into the provider port's xmlContent parameter	Exposes adapter-specific voidCertificate, outside ElectronicCertificationProvider

FEL_INTEGRATED_CERTIFIER_SLUGS currently contains only digifact. ProviderService registers digifact, infile, and rpafelapi, but adapter registration alone does not make a certifier selectable for merchants.

---

Routing decision

FelService.certifyDocument chooses the provider path before calling ElectronicCertificationProvider:

Runtime path	Provider resolution	Payload shape
Direct certifier path	document.felProviderData.providerName -> ProviderService	XML from XmlConversionService
RPAfelApi path	hard-coded rpafelapi provider	JSON DTE from XmlToDteJsonService, passed through the port as xmlContent

The business certifier configuration still matters in the RPA path. It supplies certifier credentials and the fiscal provider fields embedded in the DTE JSON.

---

Adding an integrated certifier

Before documenting a new FEL certifier as available to merchants, verify all of the following:

1. the SAT registry row exists and resolves to the intended slug
2. the certifier slug is added to FEL_INTEGRATED_CERTIFIER_SLUGS
3. direct-path URL resolution returns a usable API URL, or the product decision is to support the certifier only through RPA routing
4. ProviderService maps the slug to a working adapter for the intended path
5. RPA routing maps the internal slug through mapProviderNameToRpaFormat
6. certification, shared-info lookup, and cancellation are tested for the chosen path

If a provider supports only one path, document that as an infrastructure constraint. Do not describe it as a domain rule.

---

Common pitfalls

• infile has a provider adapter, but it is not merchant-selectable in billing settings today.
• rpafelapi is an intermediary adapter, not the fiscal certifier shown to SAT.
• RPA cancellation calls voidCertificate; that method is not part of ElectronicCertificationProvider.
• The provider port parameter is named xmlContent, but RPA certification currently passes serialized JSON through it.
• Direct certifier token refresh is not implemented in FelService; expired JWT-style direct tokens fail fast.

---

Related docs

• FEL Provider Port
• FEL certifier registry
• FEL Module Architecture