Skip to main content

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 keyRegistered adapterMerchant-selectable certifier?Direct path payloadRPA path payloadCancellation behavior
digifactProviderDigifactServiceYesXML sent to Digifact API URLDTE JSON sent through rpafelapi; certifier fields still identify DigifactDirect path certifies an ANULACION document; RPA path calls voidCertificate
infileProviderInfileServiceNoAdapter exists, but direct API URL resolution currently returns emptyDTE JSON can identify Infile if RPA mapping and credentials are validNot merchant-selectable until integration allowlist and URL behavior are updated
rpafelapiProviderRpaFelApiServiceNoNot a direct SAT certifierReceives DTE JSON serialized into the provider port's xmlContent parameterExposes 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 pathProvider resolutionPayload shape
Direct certifier pathdocument.felProviderData.providerName -> ProviderServiceXML from XmlConversionService
RPAfelApi pathhard-coded rpafelapi providerJSON 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.