@fiado/type-kit 3.53.0 → 3.54.0

package/bin/benefitCenter/dtos/AuthorizeBenefitsMarketplaceTransactionRequest.d.ts

@@ -12,15 +12,15 @@
  */
 export declare class AuthorizeBenefitsMarketplaceTransactionRequest {
     /**
-     * Reusa entradas existentes en `ProductCatalog_GT` del procesador
-     * (`MEX_TOPUP`, `MEX_SERVICE_PAYMENT`, …). No se agregan entradas nuevas
-     * en Fase 2 (ver doc §10).
+     * Id del producto del marketplace en `ProductCatalog_GT` del procesador
+     * (`MEX_TOPUP`, `MEX_SERVICE_PAYMENT`, `INTERNATIONAL_REMITTANCE`, …).
      *
-     * El factory dinámico `TransactionProcessorFactory.getMarketplaceInstance`
-     * deriva el token del binding desde aquí (`MEX_<X>` →
-     * `BenefitsMarketplace<X>TransactionService`). La regex impone el contrato
-     * y permite que el factory falle con 400 en lugar de 500 si llega algo
-     * fuera de la convención.
+     * El marketplace es multi-país y multi-servicio, así que el prefijo `MEX_`
+     * NO es obligatorio (era una convención inicial sesgada a México). La regex
+     * solo exige UPPER_SNAKE para que el factory dinámico
+     * `TransactionProcessorFactory.getMarketplaceInstance` derive el token
+     * (`<X>` → `BenefitsMarketplace<X>TransactionService`, quitando `MEX_` si
+     * está) y falle con 400 en lugar de 500 ante valores fuera de convención.
      */
     productCatalogId: string;
     /**

package/bin/benefitCenter/dtos/AuthorizeBenefitsMarketplaceTransactionRequest.js

@@ -30,8 +30,8 @@ __decorate([
     (0, class_validator_1.IsString)(),
     (0, class_validator_1.IsNotEmpty)(),
     (0, class_validator_1.MaxLength)(64),
-    (0, class_validator_1.Matches)(/^MEX_[A-Z][A-Z_]*$/, {
-        message: "productCatalogId debe seguir el formato MEX_<UPPER_SNAKE>",
+    (0, class_validator_1.Matches)(/^[A-Z][A-Z0-9_]*$/, {
+        message: "productCatalogId debe ser UPPER_SNAKE (ej. INTERNATIONAL_REMITTANCE, MEX_TOPUP)",
     }),
     __metadata("design:type", String)
 ], AuthorizeBenefitsMarketplaceTransactionRequest.prototype, "productCatalogId", void 0);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fiado/type-kit",
-  "version": "3.53.0",
+  "version": "3.54.0",
   "description": "",
   "main": "bin/index.js",
   "types": "bin/index.d.ts",

package/src/benefitCenter/dtos/AuthorizeBenefitsMarketplaceTransactionRequest.ts

@@ -26,21 +26,21 @@ import {
  */
 export class AuthorizeBenefitsMarketplaceTransactionRequest {
     /**
-     * Reusa entradas existentes en `ProductCatalog_GT` del procesador
-     * (`MEX_TOPUP`, `MEX_SERVICE_PAYMENT`, …). No se agregan entradas nuevas
-     * en Fase 2 (ver doc §10).
+     * Id del producto del marketplace en `ProductCatalog_GT` del procesador
+     * (`MEX_TOPUP`, `MEX_SERVICE_PAYMENT`, `INTERNATIONAL_REMITTANCE`, …).
      *
-     * El factory dinámico `TransactionProcessorFactory.getMarketplaceInstance`
-     * deriva el token del binding desde aquí (`MEX_<X>` →
-     * `BenefitsMarketplace<X>TransactionService`). La regex impone el contrato
-     * y permite que el factory falle con 400 en lugar de 500 si llega algo
-     * fuera de la convención.
+     * El marketplace es multi-país y multi-servicio, así que el prefijo `MEX_`
+     * NO es obligatorio (era una convención inicial sesgada a México). La regex
+     * solo exige UPPER_SNAKE para que el factory dinámico
+     * `TransactionProcessorFactory.getMarketplaceInstance` derive el token
+     * (`<X>` → `BenefitsMarketplace<X>TransactionService`, quitando `MEX_` si
+     * está) y falle con 400 en lugar de 500 ante valores fuera de convención.
      */
     @IsString()
     @IsNotEmpty()
     @MaxLength(64)
-    @Matches(/^MEX_[A-Z][A-Z_]*$/, {
-        message: "productCatalogId debe seguir el formato MEX_<UPPER_SNAKE>",
+    @Matches(/^[A-Z][A-Z0-9_]*$/, {
+        message: "productCatalogId debe ser UPPER_SNAKE (ej. INTERNATIONAL_REMITTANCE, MEX_TOPUP)",
     })
     productCatalogId!: string;