juspay/hyperswitch

Hyperswitch is an open-source payment orchestration platform that routes transactions across multiple gateways while providing a unified API compatible with Stripe. It features a sophisticated decision engine for dynamic routing, comprehensive analytics powered by ClickHouse, and robust infrastructure for fraud management, vaulting, and revenue recovery. The system supports complex payment lifecycles including extended authorizations, payouts, and mandates, with a modular architecture designed for high reliability and observability.

56 changes.

This period focused on finalizing the v2 payment and customer APIs by removing experimental feature flags and establishing stable contracts. Significant effort was dedicated to expanding the Stripe compatibility layer with Setup Intents, Webhooks, and Mandates, while refactoring the router's internal architecture to decouple connectors and standardize error handling.

58 changes.

The project underwent significant architectural refactoring, extracting core components like the scheduler, external services, and storage implementations into dedicated crates to improve modularity. Concurrently, a comprehensive analytics system was built with ClickHouse support, providing detailed sessionized metrics for payments, refunds, and API events. The period also saw the introduction of advanced features including the Euclid decision engine for dynamic routing, unified Fraud Risk Management flows, and enhanced user dashboard capabilities.

50 changes.

This period focused on expanding the analytics capabilities with comprehensive dashboards for payments, disputes, and authentication, while introducing a new OpenAPI specification generator. Significant architectural work included centralizing connector abstractions, implementing a generic events framework, and strengthening multi-tenant support through refined role management and global ID types.

36 changes.

This period focused on establishing the v2 API infrastructure, including database schema migrations, OpenAPI specifications, and a new Smithy-based model generation system. It introduced modular microservices for payment methods and subscriptions, alongside granular integration with the Unified Connector Service and external vault proxies. The work also expanded core capabilities with revenue recovery, offer engine integration, and enhanced security features like card testing guards and 3DS decision rules.

Introduces new data structures for the revenue recovery feature within the process tracker API models. This includes \RevenueRecoveryResponse\ for returning task details (such as ID, name, schedule times, and status), \RevenueRecoveryId\ for identifying specific recovery tasks, and \RevenueRecoveryRetriggerRequest\ to support resuming or retriggering tasks with optional overrides for status, business status, and retry count.

_crates/api\_models/src/process\tracker · high confidence

This update introduces new API reference documentation for the Hyperswitch Card Vault, covering both the new Locker v2 and the Rust-based locker implementations. The changes add specific reference cards for Locker v2 endpoints (such as /api/v2/vault/add and /api/v2/vault/delete) and the Rust locker endpoints (such as /data/add and /custodian/key1), alongside a general overview of the vault's architecture, key hierarchy, and setup guide.

api-reference/locker-api-reference · high confidence

The \pm\_auth\ crate now includes a new Plaid connector implementation, enabling payment method authentication flows via Plaid. This addition supports generating link tokens, exchanging public tokens for access tokens, retrieving bank account credentials, and creating payment recipients (supporting IBAN and BACS account types).

_crates/pm\auth · high confidence

This change introduces the backend implementation for SDK event analytics, specifically adding the query logic and metric accumulation required to retrieve SDK performance data from ClickHouse. It adds new modules to handle specific metrics such as payment attempts, SDK initiation and render counts, average payment time, and load time, while also providing the filtering capabilities for dimensions like payment method, platform, and browser. This functionality is exclusively available for the ClickHouse analytics provider, as SQLX is explicitly marked as not implemented for these SDK events.

_crates/analytics/src/sdk\events · high confidence

This change introduces the Smithy model definition for the Hyperswitch API, establishing the service contract for payments, refunds, customers, and mandates. The model defines the \Hyperswitch\ service (version 2024-07-31) using the \restJson1\ protocol and includes operations for creating, confirming, updating, retrieving, capturing, and canceling payments, as well as creating, retrieving, and updating refunds, and managing customer and mandate lifecycles. A corresponding \smithy-build.json\ configuration is added to generate OpenAPI 3.1.0 specifications from this model.

smithy · high confidence

Users can now retrieve logs for outgoing webhook events through a new analytics query interface. This change introduces the core logic and data structures in the analytics crate to fetch these logs, supporting filtering by identifiers such as payment, payout, refund, dispute, mandate, and attempt IDs. The implementation currently targets ClickHouse as the data source, with SQLX analytics explicitly marked as not yet implemented for this feature.

_crates/analytics/src/outgoing\_webhook\event · high confidence

A new migration route has been added to handle the migration of generic locker fingerprint IDs. This feature introduces a new API endpoint that accepts a CSV file containing merchant and payment method IDs, validates the input, and processes the migration in batches. The endpoint returns a detailed report indicating the total number of rows processed, along with counts of successful and failed migrations, allowing administrators to track the progress and outcome of the fingerprint ID migration process.

_crates/router/src/routes/payment\methods · high confidence

A new \hsdev\ binary has been added to the project, providing a standalone tool to execute Diesel-based Postgres database migrations. Users can install it via Cargo and run pending migrations by pointing it to a TOML configuration file containing database credentials (username, password, host, port, dbname) and optionally specifying a TOML table name. The tool establishes a connection to the specified Postgres instance and applies any pending migrations found in the migrations directory.

crates/hsdev · high confidence

The analytics module now includes a new distribution metric for payment error messages, allowing users to analyze the frequency and context of payment failures. This feature aggregates failure counts grouped by dimensions such as currency, status, connector, authentication type, payment method, client source, profile, card details, and error reason, while also supporting time-based granularity and top-N filtering to highlight the most common failure scenarios.

crates/analytics/src/payments/distribution · high confidence

The analytics module now supports querying a detailed audit trail of payment routing decisions. This change introduces the core logic and data structures to retrieve routing events (including connector choices, request/response details, and status codes) specifically for ClickHouse-backed analytics providers, while explicitly noting that this feature is not yet implemented for SQLX providers.

_crates/analytics/src/routing\events · high confidence

The analytics module now includes a new set of metrics under the \sessionized\_metrics\ subdirectory to support the Payments Page dashboard. These new implementations—\PaymentIntentCount\, \PaymentProcessedAmount\, \PaymentsDistribution\, \PaymentsSuccessRate\, \SmartRetriedAmount\, \SuccessfulSmartRetries\, and \TotalSmartRetries\—query the \PaymentIntentSessionized\ data source instead of the standard \PaymentIntent\ collection. This change enables the system to calculate metrics based on sessionized data, specifically allowing for the analysis of smart retry behaviors (such as total and successful retries) and first-attempt success rates.

_crates/analytics/src/payment\intents/metrics · high confidence

The Analytics V2 dashboard now includes sessionized metrics for refunds, allowing users to analyze refund data over time with granular breakdowns. This change introduces new metric implementations for refund count, processed amount, success count, success rate, error messages, and reasons, all of which support grouping by dimensions such as currency, connector, and profile, as well as time-based granularity.

crates/analytics/src/refunds/metrics · high confidence

The FiservCommerceHub connector now supports unreferenced refunds, allowing users to process refunds without linking them to an original transaction ID. This change introduces the necessary request and response structures, including HMAC signature generation for authentication and mapping of gateway states to internal refund statuses.

_crates/hyperswitch\_connectors/src/connector\relay · high confidence

A new Fluentd container setup has been introduced to ingest payment-related events (payment intents, attempts, refunds, and disputes) from Kafka topics into OpenSearch. The configuration includes specific plugins for Kafka and OpenSearch, filters to standardize timestamps, and routing rules that send data to both stdout and OpenSearch indices, with date-suffixed indices enabled for local development environments.

docker/fluentd · high confidence

A new \smithy-generator\ crate has been introduced to automatically discover Rust structs annotated with \SmithyModel\ across the workspace and generate corresponding Smithy IDL files. This tool scans enabled crates based on feature flags (such as \v1\, \v2\, \payouts\, etc.), resolves feature dependencies, and outputs the resulting model definitions to the \smithy/models\ directory, enabling automated schema generation from the existing codebase.

crates/smithy-generator · high confidence

A new \invoice\_sync\ module has been introduced to handle the synchronization of invoice and payment data for subscriptions. This workflow retrieves merchant, customer, and subscription details from storage, syncs payment status via the payments microservice, and updates the process tracker with business status, ensuring that subscription invoices remain consistent with underlying payment transactions.

crates/subscriptions/src/workflows · high confidence

The analytics crate has been reorganized into distinct modules for Payments, Payment Intents, Refunds, Fraud Risk Management (FRM), Authentication, API Events, Sdk Events, and Disputes. A new ClickHouse client implementation has been added to support ClickHouse as an analytics data source alongside the existing SQLx/PostgreSQL backend, enabling sessionized metrics for disputes and active payments. The module now exposes specific filter and metric APIs for each domain, including FRM blocked rates and triggered attempts, dispute status and amount metrics, and authentication event analytics.

crates/analytics/src · high confidence

Added a new utility module for verification operations, introducing \check\_existence\_and\_add\_domain\_to\_db\ to manage Apple Pay verified domains for Merchant Connector Accounts. This function handles fetching the account, merging new domains with existing ones, and persisting the update, supporting both v1 and v2 storage backends via feature flags. It also includes \validate\_profile\_id\_from\_auth\_layer\ to ensure profile consistency and helper functions for logging Apple Pay verification errors. Additionally, stubs for profile ID presence checks in payment intents and payouts are introduced for the v2 flow.

crates/router/src/core/verification · high confidence

The router now includes a background task that periodically records the entry count for various internal caches (such as accounts, MCAs, and routing configurations) as metrics, providing visibility into cache state. Additionally, a new utility standardizes the mapping of internal application response types to specific HTTP status codes (e.g., mapping most JSON and text responses to 200 and redirections to 302), ensuring consistent metric reporting for request outcomes.

crates/router/src/routes/metrics · high confidence

Merchants can now manage large blocklists more efficiently through new asynchronous batch operations. You can upload blocklist entries via CSV files (supporting card bins and fingerprints with optional metadata) and clone existing blocklist configurations from one business profile to others, with both processes running as background jobs to handle large datasets without blocking the API. Additionally, you can export your current blocklist entries to a CSV file for backup or auditing purposes. These features are implemented in the blocklist core module, introducing new batch processing, cloning, and export utilities.

crates/router/src/core/blocklist · high confidence

The router now includes database persistence capabilities for user themes and sample data. The new \ThemeInterface\ in \crates/router/src/db/user/theme.rs\ enables storing, retrieving, updating, and deleting themes, with support for hierarchical lineage resolution (tenant, organization, merchant, and profile levels). Additionally, the new \BatchSampleDataInterface\ in \crates/router/src/db/user/sample\_data.rs\ provides batch insert and delete operations for sample payment intents, payment attempts, refunds, and disputes, facilitating easier environment setup and testing.

crates/router/src/db/user · high confidence

The Decision Engine API reference documentation has been added, providing a comprehensive schema-backed guide for all endpoints. This includes detailed pages for core routing operations like \POST /decide-gateway\ (supporting SR, priority, debit, and multi-objective algorithms), gateway score feedback, and routing rule management. The documentation also covers merchant account lifecycle, authentication flows, and a new Analytics section with endpoints for cost savings, A/B test results, and routing stats, all generated from the OpenAPI contract.

api-reference/decision-engine-api-reference · high confidence

The Euclid routing crate now includes a new Valued Interpreter Backend (VirInterpreterBackend) alongside the existing standard Interpreter Backend. This new backend leverages a Domain Specific Static Analyzer (DSSA) to perform static analysis on routing programs, enabling optimizations such as detecting conflicting assertions and exhaustive negations before execution. The feature also introduces a benchmark suite to compare the performance of the raw interpreter against the new valued interpreter, providing users with a more efficient and robust mechanism for evaluating complex routing rules.

crates/euclid · high confidence

Payment-link pages now automatically capture and send JavaScript errors to the backend logging service. This new client-side script intercepts window errors and messages, extracts payment context (payment ID, merchant ID, attempt ID, connector) from the URL, and posts the log to an endpoint derived from the router's base URL (or a backend-provided override), ensuring logs are correctly routed even when custom domains are used.

crates/router/src/services/redirection · high confidence

This change introduces the foundational configuration files for the product. It adds \dashboard.toml\ and \dashboard\_theme.json\ to define dashboard endpoints, feature toggles (such as branding, analytics, and recon), and UI theme colors. It also adds \development.toml\ to configure the local development environment, including database connections, Redis settings, logging, and supported connectors. Finally, it adds \payment\_required\_fields\_v2.toml\ to specify the required input fields for various payment methods and connectors in the v2 payment flow.

config · high confidence

This change introduces a new Cypress v2 testing framework for the Hyperswitch payment platform. It provides end-to-end test coverage for core organizational and merchant account APIs, payment flows (including No-3DS, 3DS, and voids), and routing configurations. The suite includes configuration files for connectors like Noon, reusable test utilities, and custom Cypress commands to automate API interactions and validation.

cypress-tests-v2 · high confidence

This change introduces the complete API reference documentation for Hyperswitch, powered by Mintlify. It includes the core \docs.json\ navigation structure, an \introduction.mdx\ guide covering authentication, environments, and the payment lifecycle, and OpenAPI specifications for the Decision Engine (\decision\_engine\_openapi-specs.json\), the Locker v2 (\locker-v2.yml\), and the Rust Locker (\rust\_locker\_open\_api\_spec.yml\). The documentation also provides setup instructions in \README.md\ for generating and rendering the specs locally.

api-reference · high confidence

The scheduler module now includes a dedicated configuration structure defining settings for the producer, consumer, and server components. This change introduces default values for operational parameters such as stream names, fetch limits, batch sizes, and server ports, along with validation logic that enforces non-empty values for critical fields like the stream, consumer group, and server host at startup.

crates/scheduler/src/configs · high confidence

The v2 API reference documentation has been established, introducing a comprehensive OpenAPI 3.0.3 specification (\openapi\_spec\_v2.json\) and a structured set of Markdown pages for all v2 endpoints. This includes dedicated documentation for core resources such as organizations, merchant accounts, business profiles, customers, payment methods, payment method sessions, payments, refunds, routing algorithms, and tokenization. The documentation also covers administrative endpoints for API keys and connector accounts, as well as the new revenue recovery and proxy endpoints, providing a complete reference for the v2 API surface.

api-reference/v1, api-reference/v2 · high confidence

The routing logic in the router crate now integrates with the external Euclid Decision Engine. This change introduces new transformer implementations to map internal payment types (such as capture methods, mandate types, and payment method filters) to the Decision Engine's domain model, and adds an HTTP client layer to communicate with Decision Engine endpoints (e.g., decide-gateway, routing/evaluate). Users benefit from dynamic, rule-based routing decisions powered by the Decision Engine, replacing or augmenting previous static routing logic.

crates/router/src/core/payments/routing · high confidence

This change adds a new analytics module for API events, enabling merchants to query detailed logs and metrics for payments, refunds, disputes, and payouts via ClickHouse. The implementation provides endpoints to retrieve API logs (including fields like status code, latency, and flow type), fetch available filter dimensions (such as status codes and flow types), and retrieve aggregated metrics (API count, latency, and status code counts) over time. Authentication is scoped to the merchant ID, ensuring data isolation, and the system supports filtering by specific payment, refund, dispute, or payout IDs.

_crates/analytics/src/api\event · high confidence

Added the core implementation files for the Fraud Risk Management (FRM) framework, introducing specific flow handlers for checkout, sale, transaction, fulfillment, payout (PO), and record return scenarios. These new modules in \crates/router/src/core/fraud\_check/flows\ construct the necessary \RouterData\ structures and implement the \FeatureFrm\ trait to route fraud checks to external connectors, enabling merchants to integrate third-party fraud detection services into their payment and payout lifecycles.

_crates/router/src/core/fraud\check/flows · high confidence

This change adds the core Offer Engine module to the router, enabling merchants to integrate with an external offer service. It introduces a browse API that lists eligible offers, an apply flow that validates and applies selected offers to payments, and a connectivity check to verify the service is reachable. The implementation supports merchant-level credential configuration, handles amount conversions between Hyperswitch minor units and the engine's decimal strings, and sends payment method details (including card BIN and a PAN-free card alias for velocity checks) to the external service. Additionally, it schedules asynchronous notifications via the process tracker to report payment and refund statuses back to the Offer Engine.

_crates/router/src/core/offer\engine · high confidence

The \smithy-core\ crate now provides the core types and a generator that converts internal Rust model representations into Smithy IDL files, organizing shapes by namespace and emitting standard Smithy structures, unions, enums, and primitives with their associated traits. This is exposed via the \SmithyModel\ derive macro in the \smithy\ crate, which allows Rust structs and enums to automatically generate corresponding Smithy model definitions at compile time, including support for flattened fields and trait-based constraints like patterns, ranges, and HTTP labels.

crates/smithy-core · high confidence

This change introduces a new \crates/card\_metadata\ library that loads and validates card subtypes from an embedded TOML configuration file, ensuring data integrity for card metadata. In \crates/diesel\_models\, the database schema is restructured: the \blocklist\ and \blocklist\_fingerprint\ tables are modified to use composite primary keys (\merchant\_id\, \fingerprint\_id\) instead of auto-incrementing integer IDs, and the \locker\_mock\_up\ table similarly shifts to a \card\_id\ primary key. Additionally, the \payment\_methods\ table schema is expanded with numerous new columns to support v2 payment method features, including network tokenization, external vault details, and customer acceptance data.

_crates/diesel\models · high confidence

This change introduces the \connector\_configs\ crate, which provides the data structures and transformation logic required to expose connector settings to the merchant dashboard. It defines common configuration schemas for payment methods (including Apple Pay, Google Pay, and PayPal SDKs) and connector-specific metadata, and implements a response modifier that transforms internal connector API payloads into a structured format (\DashboardRequestPayload\) suitable for the dashboard UI.

_crates/connector\configs/src · high confidence

The analytics module now exposes a new API to fetch connector event logs, allowing users to query historical data regarding connector interactions. This feature supports filtering by payment, refund, dispute, and payout identifiers, and is available for both Prism and Hyperswitch event sources. The returned log entries include details such as the connector name, request ID, flow, latency, status code, and masked response. Additionally, the system automatically filters out 'shadow' mode events from the results to ensure users only see production-grade data.

_crates/analytics/src/connector\events · high confidence

The repository now includes a standalone Cypress testing suite (\cypress-tests\) to automate API and payment flow validation. This framework provides a structured environment for testing connectors, featuring multiple credential management, dynamic configuration, and parallel execution capabilities. It includes comprehensive documentation, a Prettier configuration, and a Cypress configuration file that sets up Mochawesome reporting, adaptive timeouts, and global state handling. The suite comes with initial test configurations for major payment processors (such as Adyen, Airwallex, Aci, and Affirm) and supports running tests in both interactive development mode and headless CI mode.

cypress-tests · high confidence

The \euclid\_macros\ crate now provides two new capabilities: the \EnumNums\ derive macro, which automatically implements a \to\_num\ method on enums with unit variants to map each variant to its index, and the \knowledge\ procedural macro, which parses a domain-specific language for defining knowledge constraints (including value comparisons, enum variants, and aggregation rules) to generate corresponding Rust code.

_crates/euclid\macros · high confidence

This change adds the backend implementation for dispute analytics, enabling users to query dispute metrics (such as disputed amounts, lost amounts, and status rates) and apply filters by connector, dispute stage, and currency. The new module supports grouping by various dimensions and includes sessionized metrics for more granular analysis, along with a filter API to discover available filter values for the dispute dimensions.

crates/analytics/src/disputes · high confidence

The new \crates/euclid\_wasm\ crate exposes a set of WebAssembly functions to the frontend, enabling client-side execution of payment routing and configuration tasks. Key capabilities include seeding and querying a knowledge graph of merchant connector accounts (\seedKnowledgeGraph\), performing currency conversion with seeded forex rates (\setForexData\, \convertCurrency\), and retrieving reference data such as two-letter country codes with names (\getTwoLetterCountryCode\) and merchant category codes with descriptions (\getMerchantCategoryCodeWithName\). The implementation leverages the \euclid\ routing engine and \hyperswitch\_constraint\_graph\ to provide these services in a browser-compatible environment.

_crates/euclid\wasm · high confidence

The \crates/events\ library now provides a generic event handling system that allows components to publish structured events with metadata to a configurable message sink. This includes a new \EventInfo\ implementation for \RequestId\ (from \router\_env\), enabling automatic inclusion of the current request identifier in event payloads. The framework supports building events with additional metadata via \EventContext\ and \EventBuilder\, serializing them with masked data, and emitting them through a \MessagingInterface\. This establishes the foundation for consistent, traceable event logging across the application.

crates/events · high confidence

The \common\_utils\ crate now defines new global ID types for customers, payments, payment attempts, payment attempt groups, refunds, tokens, payment methods, and payment method sessions. These IDs follow a \\<cell\id\>\\<entity\prefix\>\\<time\_ordered\_id\>\ format (e.g., \0a\cus\...\) to support multi-cell deployments. The implementation includes database serialization/deserialization logic for Diesel, with specific handling for V1/V2 coexistence (e.g., using \new\_unchecked\ for customer and payment method IDs to accept legacy V1 formats). These types are integrated with the event metric system to ensure proper tracking of API events associated with these entities.

_crates/common\_utils/src/id\_type/global\id · high confidence

This change adds a new client layer in \crates/payment\_methods/src/client\ that implements the create, retrieve, update, delete, list, and session flows for the modular payment method service. It defines the request and response types (including V1-facing wrappers and internal modular payloads) and wires them to the microservice client, enabling the router to interact with the new modular payment method backend for operations such as saving payment methods, fetching details, updating stored card data, and managing vault sessions.

_crates/payment\methods/src/client · high confidence

The payment methods core module now includes a new \ModularPaymentMethodError\ enum and associated result types, supporting the integration of a modular payment method update service into the payments flow. This change also establishes the error handling infrastructure (including \VaultError\) required for these new modular operations, enabling more granular error reporting for payment method creation, retrieval, and updates.

_crates/payment\methods/src/core · high confidence

The \crates/payment\_methods\ crate now provides the client-side infrastructure for the new modular payment methods microservice. This includes a \PaymentMethodClient\ for making lightweight internal service calls, configuration structs for the service URL and API prefix, and a \PaymentMethodsStorageInterface\ trait to abstract database access. The module also defines request and response types (such as \ModularPMRetrieveResponse\ and \PaymentMethodResponseData\) that bridge the v1 and v2 API contracts, enabling the router to interact with the new modular payment method flows.

_crates/payment\methods/src · high confidence

Added a new analytics module for tracking real-time active payments metrics. This includes the implementation of an accumulator to aggregate payment counts, a core service to fetch and combine metrics from the analytics provider, and the underlying query logic to load distinct payment counts filtered by merchant, publishable key, and time range.

_crates/analytics/src/active\payments · high confidence

The \crates/drainer/src\ module now implements a standalone Drainer service that reads SQL queries from Redis streams and executes them against PostgreSQL. This change introduces a new \Handler\ that manages the drainer lifecycle, including a \shutdown\_listener\ that waits for active tasks to complete before terminating (graceful shutdown) and a \spawn\_error\_handlers\ task that triggers a shutdown if the Redis connection fails. A new \health\_check\ module exposes an HTTP endpoint (\/health/ready\) that performs a deep health check by verifying connectivity and basic read/write/delete operations on both the PostgreSQL database and Redis. The service also includes comprehensive metrics for tracking job execution, stream processing times, and shutdown duration.

crates/drainer/src · high confidence

The \crates/common\_utils/src/id\_type\ module now provides dedicated, strongly-typed domain wrappers for identifiers across the platform, including \ApiKeyId\, \AuthenticationId\, \CardIssuerId\, \ClientSecretId\, \ClientSessionId\, \CustomerId\, \GlobalId\, \InvoiceId\, \MerchantId\, \MerchantConnectorAccountId\, \OrganizationId\, \PaymentId\, \PayoutId\, \ProfileId\, \ProfileAcquirerId\, \RefundReferenceId\, \RelayId\, \ResourceId\, \RoutingId\, \SubscriptionId\, \TenantId\, and \WebhookEndpointId\. These types replace raw string identifiers with type-safe structs that include built-in generation logic, database serialization (via Diesel), debug formatting, and event metric integration, ensuring consistent ID handling and reducing errors from manual string manipulation.

_crates/common\_utils/src/id\type · high confidence

The \hyperswitch\_connectors\ crate now supports unreferenced refunds for the Fiserv CommerceHub payment provider. This change adds a dedicated relay integration module (\connector\_relay.rs\) that routes unreferenced refund requests through a centralized \RelayConnectors\ enum, allowing the system to process refunds without requiring a prior transaction reference for this specific connector.

_crates/hyperswitch\connectors/src · high confidence

This change adds the core implementation files for the new granular Hyperswitch-to-UCS tunnel, including \connector\_config.rs\ for transforming connector-specific authentication and metadata, \frm.rs\ for orchestrating Fraud Risk Management lifecycle events and access tokens, \kill\_switch.rs\ for automatic fallback to shadow mode on UCS failures, and \transformers.rs\ for mapping internal payment and fraud-check data to the UCS gRPC protocol.

_crates/router/src/core/unified\_connector\service · high confidence

This change adds the API request and response structures for role management, introducing support for hierarchical permissions via parent groups and filtering by entity type. Users can now create roles using either legacy permission groups or a new parent-group-based structure, and list or retrieve roles with optional filters for entity type and group details. The API models also support responses that include parent group descriptions and scopes, enabling more granular role visibility and management.

_crates/api\_models/src/user\role · high confidence

The router now executes fraud checks through a structured flow system that supports both direct connector calls and the Unified Connector Service (UCS). The \Checkout\ flow (pre-authorization risk evaluation) is routed through UCS, handling access token acquisition and gRPC communication, while post-authorization flows like \Transaction\, \Sale\, \Fulfillment\, and \RecordReturn\ continue to use the direct path. This change also adds pre-FRM support for payouts, allowing fraud checks to block or allow payouts based on configured failure modes.

_crates/router/src/core/fraud\check · high confidence

A new Drainer application has been added to the codebase, designed to read from Redis streams and execute queries on a database. This component includes a build script that generates cargo instructions when the 'vergen' feature is enabled, and documentation explaining its purpose.

crates/drainer · high confidence

The router now includes a new \unified\_authentication\_service\ module that defines a \UnifiedAuthenticationService\ trait and supporting utilities. This framework establishes a standardized interface for handling authentication flows (pre-authentication, authentication, post-authentication, and confirmation) and provides helper functions to construct router data and execute connector calls specifically for authentication purposes. This serves as the foundational architecture for supporting diverse authentication methods, such as Click to Pay and external authentication, by decoupling the authentication logic from specific connector implementations.

_crates/router/src/core/unified\_authentication\service · high confidence

The email service now supports customizable visual themes for user-facing emails (such as verification, password reset, magic link, and invitations). The new \EmailBody\ types include specific styling fields (\primary\_color\, \background\_color\, \foreground\_color\) and \entity\_logo\_url\, allowing the system to render branded HTML templates dynamically rather than using static, hardcoded designs.

crates/router/src/services/email · high confidence

The authentication core has been refactored into a modular service structure, introducing new domain models and transformers in \crates/router/src/core/authentication\ to support external 3DS authentication flows. This change adds support for separate authentication connectors, allowing specific payment processors to handle authentication independently from the main payment flow. Users benefit from enhanced flexibility in configuring authentication providers and improved handling of external 3DS requirements, including support for pre-authentication data, SCA exemptions, and detailed authentication response tracking.

crates/router/src/core/authentication · high confidence

The router now exposes dedicated route handlers for API key management and authentication flows, supporting both v1 and v2 API contracts. The new \api\_keys.rs\ module provides create, retrieve, and update endpoints for API keys, with v1 routes requiring the merchant ID in the path and v2 routes deriving it from headers. The \authentication.rs\ module introduces endpoints for authentication creation, retrieval, and session token handling, while \apple\_pay\_certificates\_migration.rs\ adds a specific migration endpoint for Apple Pay certificates. These changes consolidate the routing logic for these critical administrative and platform operations.

crates/router/src/routes · high confidence

Added new documentation pages in the API reference essentials section, including a comprehensive guide on authentication types (Secret, Admin, Publishable, Ephemeral, and JWT keys), a detailed reference for Hyperswitch error codes and unified error codes with handling guidance, a go-live checklist for production readiness, and an explanation of API rate limits and locking behavior.

api-reference/essentials · high confidence

This change introduces three new API model sets in the user module. First, it adds support for managing dashboard metadata, including onboarding surveys, production agreements, processor setup, feedback, and saved payment views (under the v1 feature). Second, it introduces APIs for creating, updating, and retrieving user-specific themes, allowing customization of dashboard styling (colors, typography, buttons) and email configurations. Third, it adds endpoints to generate and delete sample transaction data, with filters for connector, amount range, currency, and date.

_crates/api\models/src/user · high confidence

The Payments and Refunds analytics modules have been rewritten to support the new Analytics V2 dashboard. This change introduces a new query and accumulation architecture that handles metrics (such as success rates, counts, and processed amounts) and distributions (such as error messages and failure reasons) with support for sessionized data. It adds new filtering capabilities for payments, including card network, routing approach, signature network, and first attempt, and introduces debit routing savings metrics. The refund module now supports sessionized reason and error message distributions.

crates/analytics/src/payments · high confidence

Added four new Dockerfiles to support specific build and runtime needs: a migration runner image for offline database migrations using Diesel, dedicated Dockerfiles for building Payment Link and Euclid WASM modules, and a web client image for running the Hyperswitch web interface. These images provide isolated environments for database schema management, WebAssembly compilation, and frontend development respectively.

docker · high confidence

The router now publishes structured Kafka events for authentication, disputes, fraud checks, and payment attempts/intents. New serializable models (KafkaAuthentication, KafkaAuthenticationEvent, KafkaDispute, KafkaDisputeEvent, KafkaFraudCheck, KafkaFraudCheckEvent, KafkaPaymentAttempt, KafkaPaymentAttemptEvent, KafkaPaymentIntent, KafkaPaymentIntentEvent) map domain data to Kafka payloads, with separate v1 and v2 variants for payment attempts/intents to support the v2 API. Timestamps use nanosecond precision in the \*\_event variants and millisecond precision in the base variants. The Kafka service also includes a dedicated, durability-hardened Kafka producer (deja\_record\_sink) for recording sink events on a single topic with idempotent delivery, bounded buffering, and marker envelopes for loss accounting.

crates/router/src/services/kafka · high confidence

This change adds OpenAPI specification route definitions for several new and existing resources in the \crates/openapi/src/routes\ directory. It introduces full CRUD and list operations for API keys (v1 and v2), authentication flows (create, eligibility, authenticate, redirect, sync), blocklist management (count, lookup, toggle, add/remove, list, batch upload), card issuers (CRUD, list), customers (v1 and v2), disputes (retrieve, list, accept, evidence management, aggregate), GSM rules (CRUD), mandates (retrieve, revoke, list), and merchant accounts (v1 and v2). The definitions cover both v1 and v2 API versions where applicable, specifying paths, request/response bodies, security requirements, and operation IDs for these endpoints.

crates/openapi/src/routes · high confidence

A new \crates/openapi\ crate has been introduced to centralize and automate the generation of OpenAPI specification files. The tool supports mutually exclusive \v1\ and \v2\ build features, allowing users to generate either the v1 or v2 API documentation. It reads route definitions from the \routes\ module and outputs the corresponding JSON specification files (\api-reference/v1/openapi\_spec\_v1.json\ or \api-reference/v2/openapi\_spec\_v2.json\). For the v1 spec, it also injects a custom \x-mcp\ extension into the output.

crates/openapi/src · high confidence

The Analytics V2 Dashboard now includes a dedicated Payments page backed by ClickHouse, providing detailed insights into payment intent performance. This update introduces metrics such as payment intent counts, success rates, and processed amounts, with specific support for tracking smart retries (both counts and amounts, with and without retries). Users can also visualize payment flow transitions via Sankey diagrams that break down statuses by refund and dispute states. The feature supports filtering by dimensions including status, currency, profile, connector, payment method, and customer ID, and includes sessionized metrics for more granular time-series analysis.

_crates/analytics/src/payment\intents · high confidence

The \test\_utils\ crate now includes a Rust CLI (\main.rs\) and runner logic (\newman\_runner.rs\) that executes Postman collections via Newman. This tool allows users to run connector or user module tests with configurable custom headers (\--header\) and request delays (\--delay-request\), reading authentication credentials from a TOML file specified by \CONNECTOR\_AUTH\_FILE\_PATH\. It also supports filtering tests by folder and automatically restores modified files via Git after execution.

_crates/test\utils/src · high confidence

The analytics API models have been expanded to support new reporting capabilities. The \payments\ module now includes client-side dimensions (source, version) and routing-specific filters (signature network, issuer regulation, debit routing). The \disputes\ module adds currency as a dimension and filter, along with sessionized metrics. The \auth\_events\ module introduces extensive filtering and metrics for authentication flows, including device, browser, and issuer details. Additionally, new modules define models for API event logs, connector events, fraud risk management (FRM) metrics, and SDK events.

_crates/api\models/src/analytics · high confidence

The authentication analytics module now includes dedicated metrics for tracking 3D Secure challenge flows (attempts, successes, and total flow counts) and SCA exemption outcomes (requests and approvals). These new metrics allow merchants to analyze the performance and friction of decoupled authentication challenges and exemption handling alongside existing success and error counts.

_crates/analytics/src/auth\events/metrics · high confidence

The \crates/analytics/src/auth\_events\ directory introduces a new analytics module for tracking authentication events. This includes an accumulator system to aggregate metrics such as authentication counts, success rates, challenge/frictionless flow counts, and exemption statistics. The module provides core logic to fetch these metrics and available filter dimensions (like authentication status, connector, and country) from the analytics provider, supporting both Clickhouse and SQL backends. It also implements specific query builders for generating Sankey diagram data based on authentication status and type, enabling users to visualize authentication funnels and exemption flows.

_crates/analytics/src/auth\events · high confidence

The router now supports revoking authentication tokens via a Redis-backed blacklist for users, roles, and email tokens, ensuring invalidated credentials are rejected. It also introduces HTTP-only, secure cookie handling for JWT tokens and adds support for generating and validating embedded tokens for multi-tenant scenarios.

crates/router/src/services/authentication · high confidence

The router now includes a comprehensive set of new HTML email assets in the \crates/router/src/services/email/assets\ directory, replacing or supplementing previous inline or basic text formats. These templates provide a consistent, branded experience for key user and administrative events: authentication flows (magic link login, email verification, password reset), user management (new user invites, role revocation notifications), and system alerts (API key expiry warnings, production account intent approvals, and reconciliation dashboard access grants). Additionally, a dedicated template is provided for the open-source community welcome email, ensuring appropriate messaging for public-facing signups.

crates/router/src/services/email/assets · high confidence

The \crates/cards\ library now introduces dedicated types for card security code (\CardSecurityCode\), expiration month (\CardExpirationMonth\), and expiration year (\CardExpirationYear\), each enforcing strict validation rules (e.g., CSC 0-9999, month 1-12, year \>= current). It also adds a \CardExpiration\ struct with an \is\_expired\ method that correctly handles timezone offsets and calendar logic. Additionally, \validate.rs\ defines \CardNumber\, \CardBin\, and \NetworkToken\ types with support for BIN extraction (6-10 digits), offer engine BIN (up to 9 digits), blocklist prefix generation, and co-badged card detection via network regex matching.

crates/cards/src · high confidence

The \crates/common\_types\ module has been introduced to centralize shared types across the payment domain. This includes structured models for split payments (Stripe, Adyen, Xendit, and Payload), connector webhook setup capabilities, and 3DS decision rule engine configurations. It also adds support for customer document validation (CPF, CNPJ, PSN), dispute network details (Visa Rapid Dispute Resolution), and payment method enablement settings. Additionally, it provides primitive wrappers for boolean flags related to extended and partial authorization, and implements EMI interest calculation logic with corresponding tests.

_crates/common\types · high confidence

A new command-line tool, \config\_importer\, has been added to the \crates/config\_importer\ crate. It reads a Hyperswitch TOML configuration file and converts its contents into a list of environment variable key-value pairs. The tool supports specifying a custom prefix (defaulting to \ROUTER\) for the generated variable names and outputs the result in Kubernetes-compatible JSON format by default. Users can direct the output to a file using the \--output-file\ flag or view it in the console.

_crates/config\importer · high confidence

A new \currency\_conversion\ crate has been added to provide currency conversion functionality. It introduces a \convert\ function that transforms amounts between currencies using a set of exchange rates with a specified base currency. The implementation supports conversions from any supported currency to the base, from the base to any supported currency, and between two non-base currencies by routing through the base. It includes error handling for unsupported currencies and decimal multiplication failures, and relies on \rusty\_money\ for currency matching and \rust\_decimal\ for precise arithmetic.

_crates/currency\conversion · high confidence

Administrators can now migrate customer records to use global IDs via a new API endpoint. This change introduces a route that accepts a CSV file (limited to 1MB and 500 records) containing merchant and customer IDs. The system processes these records in parallel batches, updating existing customers or skipping those that already have global IDs, and returns a detailed report of updated, skipped, and failed rows.

crates/router/src/routes/customers · high confidence

The router's database layer now exposes dedicated storage interfaces for managing API keys, payment authorizations, and blocklist batch jobs. The \ApiKeyInterface\ adds support for inserting, updating, revoking, and listing API keys, with optional in-memory cache invalidation when the \accounts\_cache\ feature is enabled. The \AuthorizationInterface\ provides methods to store and retrieve incremental authorization records, including a fallback lookup strategy that handles legacy records lacking a \processor\_merchant\_id\. The \BatchBlocklistJobInterface\ introduces tracking for asynchronous blocklist operations, allowing merchants to monitor the status of profile-scoped blocklist cloning jobs.

crates/router/src/db · high confidence

The \router\_derive\ crate now exposes several new procedural macros to reduce boilerplate and improve type safety: \ApplyChangeset\ for generating changeset logic, \FromNew\ for initialization, \GeneratePermissions\ for authorization, \GenerateSchema\ for polymorphic schema generation, \ToEncryptable\ for encryption handling, \ValidateSchema\ for struct attribute validation, and \ValidateXssOrSqli\ for input sanitization. Additionally, the existing \DieselEnum\ macro has been enhanced to support a \storage\_type\ attribute, allowing enums to be stored as text in the database rather than only as database-specific enum types, and a new \DieselEnumText\ macro is provided for this text-based storage mode. The \Setter\ macro now uses \\#\[automatically\_derived\]\ for better IDE support and stricter compile-time error handling.

_crates/router\derive/src · high confidence

This change introduces a suite of new shell scripts to streamline development workflows. The \add\_connector.sh\ script automates the generation of connector templates and updates all necessary configuration files, enum definitions, and routing mappings across the Rust workspace. A new \hyperswitch-explore.sh\ script provides a zero-config local environment setup, handling Kubernetes deployment, port forwarding, and seeding dummy transactions. Additionally, \setup.sh\ offers a one-click Docker installation, while \create\_default\_user.sh\ automates the creation of a demo merchant account with pre-configured connectors. Legacy scripts for manual merchant and connector account creation have been removed in favor of these automated tools.

scripts · high confidence

The dispute analytics module now exposes three new metric implementations: dispute status counts, total disputed amounts, and total lost amounts. These metrics allow users to query dispute data grouped by dimensions such as currency and connector, with support for time-range filtering and granularity. The dispute status metric returns counts of disputes by their current status, while the total disputed and total lost amount metrics aggregate the monetary values of disputes, with the latter specifically filtering for lost disputes. All metrics return results as a HashSet of bucket identifiers and metric rows, enabling flexible client-side processing.

crates/analytics/src/disputes/metrics · high confidence

The \common\_utils\ crate introduces several new domain types to support platform-level authentication, key management, list pagination, and extended authorization. \authentication.rs\ defines an \AuthInfo\ enum with \OrgLevel\, \MerchantLevel\, and \ProfileLevel\ variants to support analytics and authentication at different organizational tiers, alongside a \ResourceId\ enum for client secrets. \keymanager.rs\ introduces the \KeyManagerState\ struct and request/response types (e.g., \EncryptionCreateRequest\, \BatchEncryptDataRequest\) to manage encryption services, including tenant ID resolution and legacy key store compatibility. \list.rs\ adds validated \PageSize\ and \PageOffset\ types to enforce pagination limits and prevent excessive data retrieval. Finally, \primitive\_wrappers.rs\ defines boolean wrappers (\ExtendedAuthorizationAppliedBool\, \RequestExtendedAuthorizationBool\, \AlwaysRequestExtendedAuthorization\) for database serialization, supporting extended authorization features.

_crates/common\utils/src/types · high confidence

The router now includes a built-in dummy connector (supporting PhonyPay, FauxPay, PretendPay, and test modes for Stripe, Adyen, Checkout, and PayPal) that allows developers to simulate payment flows without external integrations. This feature adds dedicated routes for creating and retrieving payments, authorizing transactions via a customizable HTML page, completing or rejecting payments, and processing refunds. It supports multiple payment methods including cards, UPI collect, wallets, and pay-later options, with all state managed in Redis and configurable delays to mimic real-world latency.

_crates/router/src/routes/dummy\connector · high confidence

The \router\_env\ crate now provides a comprehensive set of utilities for build-time metadata, observability, and request handling. Build scripts can use the new \vergen\ module to embed git commit hashes, timestamps, and Rust compiler details into the binary, while \cargo\_workspace\ allows crates to deterministically discover other workspace members at compile time. For observability, new macros (\global\_meter\, \counter\_metric\, \histogram\_metric\_f64\, \gauge\_metric\) simplify the creation of OpenTelemetry metrics, and the \Env\ enum now supports an 'Integ' environment with lowercase serialization for config file naming. Additionally, the crate introduces a request ID middleware (\RequestIdentifier\) that automatically generates or reuses UUIDs for HTTP requests, integrates with \tracing-actix-web\ via a custom root span builder, and supports protocol-faithful replay recording via the \deja\ feature.

_crates/router\env/src · high confidence

The router now includes dedicated event data structures in the \events\ module to capture detailed logs for various system activities. This adds support for recording API request/response details (including latency, status codes, and authentication info), audit trails for payment lifecycle events (such as creation, confirmation, capture, and rejection), and outgoing webhook delivery statuses (including retry attempts and error details). These structures standardize how operational data is serialized and prepared for downstream analytics and monitoring systems.

crates/router/src/events · high confidence

The router now includes specific helper logic to validate and retrieve files associated with dispute evidence. When a user uploads a file for a dispute, the system validates the file purpose and size against the connector's requirements before storage. Additionally, a new retrieval flow allows users to fetch previously uploaded dispute evidence files directly from the payment connector, handling the necessary connector integration and error responses for missing or unavailable files.

crates/router/src/core/files · high confidence

This change introduces five new Protocol Buffer definitions that establish the gRPC interfaces for several backend services. The \success\_rate.proto\ file defines the \SuccessRateCalculator\ service, enabling dynamic routing based on success rates with support for exploration/exploitation strategies and global rate calculations. The \contract\_routing.proto\ and \elimination\_rate.proto\ files define \ContractScoreCalculator\ and \EliminationAnalyser\ services, respectively, which handle contract scoring and elimination bucket management for routing decisions. Additionally, \recovery\_decider.proto\ specifies the \Decider\ service interface for payment recovery logic, including retry history and decision thresholds, while \health\_check.proto\ provides a standard gRPC health check service for monitoring service availability.

proto · high confidence

A new \crates/injector\ library has been added to handle token replacement and request injection for external vault proxies (specifically VGS). This standalone component manages HTTP client configuration with proxy and TLS/mTLS support, parses vault metadata from the \x-external-vault-metadata\ header to dynamically route requests, and exposes observability metrics for invocation counts, success/failure rates, and performance latencies.

crates/injector · high confidence

The \kgraph\_utils\ crate has been introduced to provide a constraint-graph-based evaluation engine for determining which payment methods are eligible for a given transaction. This library constructs a directed graph from Merchant Connector Account (MCA) configurations and evaluates it against payment context (such as currency, amount, and card network) to return valid payment options. It includes benchmarking tools for graph evaluation performance and defines specific error types for graph construction and analysis failures.

_crates/kgraph\utils · high confidence

A new utility module has been added to the common metrics library, introducing two helper functions: \time\_future\ and \record\_operation\_time\. These functions allow developers to easily measure and record the execution time of asynchronous operations as OpenTelemetry histograms, facilitating better observability and performance monitoring within the application.

_crates/common\utils/src/metrics · high confidence

The router introduces a dedicated \services/authentication\ module that centralizes and expands authentication logic. It supports multiple authentication types including API keys, JWTs (Organization, Merchant, User, Single-Purpose), Publishable Keys, and SDK Authorization. The module also implements role-based access control with caching in Redis, a card testing guard service using Redis for rate limiting, and OIDC provider integration for SSO. Additionally, it includes Kafka event publishing for analytics and authentication events, and a payment method authentication service for connector processing steps.

crates/router/src/services · high confidence

The payment methods core logic has been restructured into a new modular service under \crates/router/src/core/payment\_methods\. This introduces a dedicated client listing endpoint (\GET /payments/{payment\_id}/client\) that combines merchant-enabled payment methods with customer saved payment methods, using a pinning mechanism to ensure token consistency across concurrent requests. The module also includes an access token service for external vaults, a batch retrieval endpoint for bulk payment method data, and a backward compatibility layer that triggers inline or scheduled tasks to backfill legacy data during payment method creation.

_crates/router/src/core/payment\methods · high confidence

The router now includes dedicated flow handlers for several advanced payment operations. The \cancel\_post\_capture\_flow\ and \cancel\_post\_capture\_sync\_flow\ modules implement the logic for voiding payments after they have been captured, including synchronous status checks. The \extend\_authorization\_flow\ and \incremental\_authorization\_flow\ modules enable merchants to extend the validity period of an authorization or increase the authorized amount on existing transactions. Additionally, the \external\_proxy\_flow\ module introduces support for external vault proxy payments, allowing integrations to route authentication through third-party vaults. These flows are implemented as new Rust modules in the \crates/router/src/core/payments/flows\ directory, providing the core execution logic for these specific API endpoints.

crates/router/src/core/payments/flows · high confidence

The router now supports two new core payment operation flows. The \ExternalVaultProxyPaymentIntent\ flow enables payments to be confirmed through an external vault proxy, handling validation and tracker retrieval for intents in 'requires\_payment\_method', 'failed', or 'processing' states. Additionally, the \PaymentApprove\ flow allows merchants to manually approve payments that are pending review, validating that the intent is not already failed, succeeded, or in a review state before proceeding.

crates/router/src/core/payments/operations · high confidence

This change introduces the frontend HTML, CSS, and JavaScript templates for the payout link and payment method collect flows within the generic link module. The payout link templates now include a dedicated status page that displays merchant branding, session status (success, pending, failed, etc.), and error details, along with client-side logic to handle secure redirections when the content is viewed in an iframe or test mode. Additionally, new templates and scripts are provided for the payment method collect initiation and status views, enabling merchants to collect payment methods via a branded widget.

_crates/router/src/core/generic\link · high confidence

The system now includes a new \predefined\_roles.rs\ module that establishes static role configurations for internal administrators, tenant admins, and organization admins. These roles are mapped to specific permission groups (such as Operations, Connectors, Workflows, Analytics, Users, Account, and Reconciliation) and are scoped to their respective entity types (Internal, Tenant, Organization). This change provides the foundational role definitions used by the authorization service, ensuring consistent permission assignments across these higher-level scopes.

crates/router/src/services/authorization/roles · high confidence

The \router\_derive\ crate introduces several new procedural macros to automate common patterns. The \apply\_changeset\ macro generates an \apply\_changeset\ method on structs to selectively update target objects, handling \Option\ fields by only applying \Some\ values. The \from\_new\ macro implements \From\<EntityNew\> for Entity\ for structs following the \{Name}New\ naming convention. A new \generate\_permissions\ macro automates the creation of \Permission\ enums and associated \Resource\/\Entity\ mapping traits based on declarative input. Additionally, \generate\_schema\ provides polymorphic schema generation with field-level mandatory/hidden controls, while \to\_encryptable\ supports batch encryption/decryption logic. Existing macros like \api\_error\ and \diesel\ were also updated to use \\#\[automatically\_derived\]\ and support new features like the \ignore\ attribute for error fields.

_crates/router\derive/src/macros · high confidence

The router now includes a suite of new Process Tracker workflows in the \workflows\ module to handle background tasks. API key expiry reminders are now sent via a dedicated workflow that respects merchant-specific email themes. Blocklist management is supported through workflows for exporting data to CSV, uploading batch blocklists, and cloning entries across business profiles. Dispute list synchronization with connectors is now handled by a scheduled workflow, and network tokenization for payment methods is processed asynchronously. Additional workflows manage invoice synchronization for subscriptions and provide automatic retry logic for outgoing webhook deliveries.

crates/router/src/workflows · high confidence

The Analytics V2 Payments page now includes a suite of new sessionized metrics, implemented in \crates/analytics/src/payments/metrics/sessionized\_metrics\. These new modules—\avg\_ticket\_size\, \connector\_success\_rate\, \debit\_routing\, \failure\_reasons\, \payment\_count\, \payment\_processed\_amount\, \payment\_success\_count\, \payments\_distribution\, \retries\_count\, and \success\_rate\—enable merchants to analyze payment performance over time with granular filtering. The metrics support dynamic grouping by dimensions such as currency, connector, and payment method, and incorporate new filtering capabilities for routing approach, signature network, and issuer regulation status.

_crates/analytics/src/payments/metrics, crates/analytics/src/payments/metrics/sessionized\metrics · high confidence

The \sessionized\_metrics\ module in the analytics crate now includes implementations for refund-specific metrics, enabling the Analytics V2 dashboard to display detailed refund data. This change adds new metric handlers for refund count, processed amount, success count, success rate, refund reason, and refund error message. These components query the \RefundSessionized\ analytics collection, allowing users to analyze refund performance and failure reasons across various dimensions and time granularities.

_crates/analytics/src/refunds/metrics/sessionized\metrics · high confidence

The \crates/storage\_impl\ crate has been introduced to centralize storage backend implementations for various data structures and objects. This location now provides the concrete \DatabaseStore\ and \RouterStore\ implementations for the \ProfileInterface\ (business profiles), \CardIssuersInterface\ (card issuer management), and \CardsInfoInterface\ (card information), along with the \Conversion\ traits required to map between domain models and diesel storage models. It also includes the foundational \KvStorePartition\ implementations for entities like \Address\ and \Capture\, and the \MasterKeyInterface\ implementations for accessing encryption keys across the different store types.

_crates/storage\impl · high confidence

This change introduces the core implementation for the subscription management system within the new \crates/subscriptions\ crate. It adds handlers for managing the subscription lifecycle (creation, customer association, and database persistence), processing invoices (creation, updates, and payment confirmation), and integrating with external billing processors (creating customers and subscriptions on connectors). Additionally, it includes an internal API client to communicate with the payments microservice for handling subscription-related payments.

crates/subscriptions/src/core · high confidence

The \crates/subscriptions\ module has been introduced to centralize subscription logic, providing the core implementation for creating subscriptions (\create\_subscription\), retrieving subscription items (\get\_subscription\_items\), and handling incoming webhooks for invoice generation and MIT payments (\incoming\_webhook\_flow\). This change includes the necessary state management (\SubscriptionState\), storage interfaces, and helper types to support the subscription feature set.

crates/subscriptions/src · high confidence

This change introduces new domain-level types in the router's user module to support recent user-facing capabilities. It adds \dashboard\_metadata.rs\ to define the structure for storing and retrieving dashboard metadata (such as onboarding status, processor connections, and saved payment views) and maps these to database enums. It introduces \decision\_manager.rs\, which implements the logic for managing user authentication flows (including SSO, TOTP, and password resets) and resolving lineage context from the database to ensure correct role validation. It adds \oidc.rs\ to define the data structures for OIDC authorization code and token claims, supporting OpenID Connect integration. Finally, it adds \user\_authentication\_method.rs\ to define and populate a default password-based authentication method for the system.

crates/router/src/types/domain/user · high confidence

This change introduces new data structures in the user types module to support theme-related APIs and lineage tracking. It adds a \LineageContext\ struct for storing user hierarchy information (user, merchant, role, org, profile, tenant IDs) in the database, and a \ThemeLineage\ enum to represent the hierarchical lineage of entities (Tenant, Organization, Merchant, Profile) for theme queries. Additionally, it defines an \EmailThemeConfig\ struct to hold email-specific theme settings such as entity name, logo URL, and color schemes.

_crates/common\utils/src/types/user · high confidence

This change introduces a suite of new utility modules in the router's user utilities to support enhanced user management features. It adds \password.rs\ for handling Argon2 password hashing and temporary password generation, \two\_factor\_auth.rs\ for managing TOTP and recovery code state in Redis, and \theme.rs\ for handling theme versioning and file storage operations. Additionally, \dashboard\_metadata.rs\ provides the backend logic for storing and retrieving user and merchant-scoped metadata, including saved views, while \sample\_data.rs\ enables the generation of randomized test data for payments, refunds, and disputes. A new \blocker\_emails.txt\ file is also added to maintain a list of blocked email domains.

crates/router/src/utils/user · high confidence

This change introduces several new capabilities in the user core module. Users can now manage dashboard metadata (such as production agreements, onboarding surveys, and reconciliation status) via new set and get endpoints. A new sample data feature allows users to generate and delete randomized payment intents, attempts, refunds, and disputes for testing purposes. Additionally, users can mint federated HyperSage trace sessions via a new POST /user/launch\_trace endpoint, and the system now supports creating, updating, and retrieving themes with associated email configurations and file storage.

crates/router/src/core/user · high confidence

Added new route handlers in the user routes module to allow users to create, read, update, and delete their own themes via JWT authentication. These endpoints (\create\_user\_theme\, \get\_user\_theme\_using\_theme\_id\, \update\_user\_theme\) are distinct from the existing admin-only theme operations, enabling organization and platform users to manage theme assets directly.

crates/router/src/routes/user · high confidence

The \crates/router/src/core/relay/utils.rs\ module has been added, introducing \construct\_relay\_refund\_router\_data\ and \construct\_relay\_capture\_router\_data\. These functions provide the necessary data structures to process refunds and captures for relay records, handling connector authentication, API versioning, and webhook URL generation specifically for these relay flows.

crates/router/src/core/relay · high confidence

The router now includes dedicated utility modules in \crates/router/src/utils\ to support new capabilities: \connector\_onboarding.rs\ provides functions to check connector existence and manage tracking IDs in configuration storage; \oidc.rs\ implements OpenID Connect flows including authorization code handling in Redis and JWT token signing; \currency.rs\ introduces a forex rate caching system with local and Redis storage, API fallbacks, and expiration logic; \user\_role.rs\ adds validation for role groups and names, plus caching for role information; \verify\_connector.rs\ supplies test card generation for connectors like Stripe and PayPal. Additionally, \crypto.rs\ and \custom\_serde.rs\ have been removed, and \ext\_traits.rs\ has been refactored to re-export \OptionExt\ from \hyperswitch\_domain\_models\.

crates/router/src/utils · high confidence

The payment link crate now exposes template generation capabilities via a WebAssembly (WASM) build, allowing payment link HTML previews and configuration validation to run in the browser. This includes a new build script that embeds environment-specific SDK URLs at compile time, a CSS generator that safely sanitizes and applies custom UI rules, and a JavaScript generator that converts configuration data to the format expected by the frontend SDK. A default merchant logo is also provided for previews where none is specified.

_crates/payment\link · high confidence

Payout link pages (initiation and status views) now render text in the user's preferred language. The system extracts the primary language from the request locale and populates the template context with translated strings for titles, month names, time indicators (AM/PM), and status messages (success, processing, failed).

_crates/router/src/services/api/generic\_link\response · high confidence

The router's payout core now handles connector access tokens, automatically fetching, caching, and refreshing them for supported connectors to ensure uninterrupted payout processing. Additionally, the system implements automated retry mechanisms for failed payouts, allowing single-connector or multi-connector retries based on Gateway Status Map (GSM) configurations, and enforces pre-connector blocklist checks to block payouts against restricted payment methods before they reach the connector.

crates/router/src/core/payouts · high confidence

The \router\_derive\ crate now includes a new procedural macro located in \crates/router\_derive/src/macros/schema\ that validates schema attributes on structs. This implementation introduces helper logic to parse and enforce specific metadata keywords—such as \value\_type\, \min\_length\, \max\_length\, \example\, and \deprecated\—on struct fields. It ensures that these schema parameters are correctly extracted and validated during compilation, providing a mechanism to enforce structural constraints and documentation metadata directly within the Rust codebase.

_crates/router\derive/src/macros/schema · high confidence

The Redis interface now supports two interchangeable backends: the existing redis-rs client and the new fred-rs client. This change introduces a modular architecture in \crates/redis\_interface/src/module\ where \redis\_rs.rs\ and \fred.rs\ each provide their own connection pools, pub/sub subscribers, and command implementations. Both backends share a common set of types and commands, allowing the system to switch between clients via feature flags while maintaining consistent behavior for operations like key setting, stream reading, and pub/sub messaging.

_crates/redis\interface/src/module · high confidence

Added new utility modules for refund processing: \refunds\_transformers.rs\ defines the \SplitRefundInput\ struct to handle split refund data, and \refunds\_validator.rs\ introduces validation logic for refund amounts, payment order age, maximum refund counts, and connector-specific refund support (including specific handling for Stripe split refunds and Braintree PayPal restrictions).

crates/router/src/core/utils · high confidence

A new \request.rs\ module has been added to the analytics metrics crate, introducing a \record\_operation\_time\ function. This utility wraps asynchronous operations to measure their execution duration and records the result as an OpenTelemetry histogram metric, tagged with the metric name and analytics source. This enables users to monitor request latency and performance characteristics within the analytics subsystem.

crates/analytics/src/metrics · high confidence

The router now stores retry statistics for revenue recovery operations in the database, enabling historical analysis of retry outcomes. This change introduces a new storage layer that records retry events (success/failure) clustered by error code, card type, and issuer, using a best-effort approach with Redis locking to handle concurrent updates safely. Additionally, an API endpoint has been added to migrate pre-aggregated retry stats from CSV uploads into the database, supporting data backfilling and validation with detailed error reporting for failed rows.

_crates/router/src/core/revenue\_recovery/retry\stats · high confidence

The router now supports Stripe-compatible Setup Intents, allowing users to create and manage payment methods for future use via the Stripe API format. This change adds the necessary type definitions and request transformation logic in the \crates/router/src/compatibility/stripe/setup\_intents\ module, mapping Stripe-specific fields (such as \payment\_method\_data\, \billing\_details\, and \metadata\) to the internal payment request structures. This enables seamless integration with clients expecting Stripe's Setup Intent workflow.

_crates/router/src/compatibility/stripe/setup\intents · high confidence

The Stripe compatibility layer in \crates/router/src/compatibility/stripe\ has been updated to align with the platform authentication model. Existing endpoints for Payment Intents, Customers, and Refunds now use the unified \auth::HeaderAuth\ mechanism, allowing them to support both platform self-operations and connected-scope operations where applicable (e.g., Customers and Payment Intents creation). A new \SetupIntents\ module has been added, exposing create, retrieve, update, and confirm endpoints that map to the internal \SetupMandate\ flow. Additionally, a new \Webhooks\ scope has been introduced to handle incoming Stripe-compatible webhooks, and the \Mandates\ scope now exposes a detach endpoint. The error handling has also been expanded with new Stripe-compatible error codes for disputes, payouts, and mandates.

crates/router/src/compatibility/stripe · high confidence

The \transformers.rs\ file for the Checkout connector has been deleted, removing the local data structures and conversion logic (such as \PaymentsRequest\, \PaymentsResponse\, and status mappings) that previously handled serialization and deserialization for this connector.

crates/router/src/connector/checkout · high confidence

The scheduler consumer, producer, types, utilities, and workflow execution modules have been removed from the router crate. This eliminates the legacy ProcessTracker implementation that previously managed task scheduling and execution via Redis streams, effectively stripping out the internal mechanics for dispatching and processing scheduled workflows from this location.

crates/router/src/scheduler · high confidence

The payment sync workflow implementation in the scheduler module has been removed. This eliminates the automated background process that previously retried payment status checks against connectors when initial attempts did not reach a terminal state, effectively stopping the system from automatically resynchronizing payment statuses via this specific scheduled mechanism.

crates/router/src/scheduler/workflows · high confidence

The dedicated refund validation module has been removed from the router core. This change eliminates the specific validation rules that previously enforced constraints such as maximum refund age, maximum number of refund attempts, and checks for duplicate refund IDs against payment attempts.

crates/router/src/core/refunds · high confidence

The source files for the \hyperswitch\_masking\ crate (including \Secret\, \StrongSecret\, and related traits) have been deleted from \crates/masking/src\. This indicates the masking logic has been removed from this location, likely as part of a migration to a different implementation or external dependency.

crates/masking/src · high confidence

The \transformers.rs\ file in the Authorized.net connector module has been deleted. This removes the local data structures and serialization logic previously used to map internal payment requests to the Authorized.net API format, indicating a refactoring of how this connector constructs its API payloads.

crates/router/src/connector/authorizedotnet · high confidence

The \common\_enums\ crate now serves as the single source of truth for core payment domain types, consolidating enums previously scattered across \storage\_models\ and \api\_models\. This includes the \Connector\ enum (listing all supported payment gateways like Adyen, Stripe, and Calida), \AttemptStatus\, \IntentStatus\, and country code representations (\CountryAlpha2\, \CountryAlpha3\). By centralizing these definitions, the system ensures consistent serialization, database storage, and API schema generation for payment flows across the platform.

_crates/common\enums/src · high confidence

The connector integration code for Aci, Adyen, Authorizedotnet, Checkout, and Stripe has been removed from the router crate and relocated to the hyperswitch\_connectors crate. This architectural change decouples connector-specific logic from the core router, simplifying the router's codebase while preserving the existing payment processing capabilities through the new modular structure.

crates/router/src/connector · high confidence

Connector logic for multiple providers (including Adyen, Braintree, Nuvei, Stripe, and others) has been moved from the main router crate into the dedicated \hyperswitch\_connectors\ crate. This architectural change isolates connector-specific code, improving modularity and maintainability without altering the external payment processing behavior.

_crates/hyperswitch\connectors/src/connectors · high confidence

The \external\_services\ crate has been introduced to centralize interactions with external systems, including AWS KMS, GCP Cloud KMS, AWS SES, SMTP, HubSpot CRM, and file storage (AWS S3 and local file system). This refactoring moves these implementations out of the router crate, providing a shared, modular layer for encryption, email delivery, CRM integration, and file management that can be reused across the workspace.

_crates/external\services · high confidence

The \crates/router/src/types\ module has been restructured to support the v2 payment flow by introducing new domain type definitions and re-exporting core models from \hyperswitch\_domain\_models\. This includes dedicated modules for authentication, fraud check (FRM), and payment methods, which define the specific request/response types and integration traits required for the new router data architecture. Additionally, \connector\_transformers.rs\ now provides the explicit mapping logic that translates API-level connector enums into the internal \RoutableConnectors\ enum, establishing the foundation for the v2 connector routing layer.

crates/router/src/types · high confidence

The \hyperswitch\_interfaces\ crate has been introduced to centralize the interface definitions and error types for the payment gateway. This change establishes a unified abstraction layer that supports both traditional direct HTTP connector integrations and the new Unified Connector Service (UCS) via gRPC. It defines the core traits for payment operations (such as authorization, capture, and sync), refunds, payouts, disputes, and fraud checks, alongside V2 versions of these interfaces that utilize a new \ConnectorIntegrationV2\ trait. Additionally, it includes a gateway abstraction (\PaymentGateway\ and \PayoutGateway\) that allows the system to seamlessly switch between execution paths (Direct, UCS, or Shadow) without requiring changes to individual flow implementations.

_crates/hyperswitch\interfaces · high confidence

The \crates/common\_utils\ crate has been introduced to centralize shared infrastructure, providing a single location for access token key generation, cryptographic operations (including AES-GCM and RSA-SHA-256), serialization formats (ISO 8601 and UNIX timestamps), error definitions, and event metric types. This consolidation moves previously scattered logic—such as constants, crypto traits, and PII encryption wrappers—into a dedicated module, ensuring consistent handling of sensitive data and standardized error reporting across the platform.

_crates/common\utils/src · high confidence

The \crates/router/src/types/api\ module has been restructured into a set of dedicated, modular files (such as \api\_keys.rs\, \authentication.rs\, \connector\_mapping.rs\, and \fraud\_check.rs\). This change consolidates the public API type re-exports and connector routing logic, making the router's API surface more organized and easier to maintain without altering the external API contract.

crates/router/src/types/api · high confidence

The scheduler's database interactions for process tracking and task queuing have been extracted into a dedicated storage interface within the scheduler crate. This change introduces \ProcessTrackerInterface\ and \QueueInterface\ traits, implemented by the scheduler's \Store\, to handle PostgreSQL operations (such as retrying, resetting, and finishing processes) and Redis operations (including consumer group management and distributed locking). This separation isolates the scheduler's persistence logic, making it easier to maintain and test independently from the core router logic.

crates/scheduler/src/db · high confidence

The scheduler implementation has been extracted from the router crate into a new \crates/scheduler\ crate. This change introduces task segregation based on application source, routing Main and CUG tasks to separate Redis streams, and ensures the Redis consumer group registers a single, stable consumer per process lifetime to prevent accumulation of stale entries.

crates/scheduler/src · high confidence

The router's storage type definitions have been consolidated into the \diesel\_models\ crate. Most files in \crates/router/src/types/storage\ are now thin re-export modules that expose types like \ApiKey\, \Profile\, \PaymentLink\, and \RevenueRecovery\ from \diesel\_models\, centralizing the database schema definitions. This change removes the legacy, in-crate Diesel models for \connector\_response\ and \payment\_intent\, which are no longer present in the storage layer, indicating a shift in how payment intents and connector responses are persisted or accessed.

crates/router/src/types/storage · high confidence

The analytics module's API event metrics (API count, latency, and status code count) have been updated to return their results as a \HashSet\ instead of a \Vec\. This change ensures that the returned metric buckets are unique and deduplicated, providing a cleaner data structure for downstream consumers of the analytics API.

_crates/analytics/src/api\event/metrics · high confidence

The \api\_models\ crate now includes event metric implementations for a wide range of API request and response types, ensuring they are correctly tracked in analytics. This covers new v2 flows for customers, payments, refunds, and payouts, as well as support for dispute management, connector onboarding, gateway status maps, dynamic routing, revenue recovery, and user role/theme management. For customer and refund operations, the event type extraction logic now distinguishes between v1 and v2 features, adapting to changes in how identifiers (like \customer\_id\ or \refund\_id\) are exposed in the new API versions.

_crates/api\models/src/events · high confidence

The authorization logic in \crates/router/src/services/authorization\ has been restructured to define permissions via explicit \PermissionGroup\ and \ParentGroup\ enums rather than ad-hoc checks. New files (\info.rs\, \permission\_groups.rs\, \permissions.rs\, \roles.rs\) establish a hierarchy where specific groups (e.g., \OperationsView\, \ReconSourcesManage\) map to parent categories (e.g., \Operations\, \ReconSources\) and define read/write scopes, accessible sub-groups, and associated resources. This change introduces a more structured, hierarchical permission model that supports granular access control for features like reconciliation, offers, and superposition configs, while hiding certain internal or admin-only groups from user-facing authorization info responses.

crates/router/src/services/authorization · high confidence

A new helper module in the payments routes now automatically populates browser information for payment requests, specifically extracting the client IP address from the request connection info and the accept-language from the header payload if not already provided. Additionally, it ensures that online mandate data includes the inferred IP address. The module also introduces logic to determine whether a payment request should be routed through the proxy for payments core, specifically checking for flows involving network transaction IDs, network tokens, decrypted wallet tokens, or limited card details.

crates/router/src/routes/payments · high confidence

The router environment crate now includes a build script that generates Cargo instructions and sets workspace member environment variables at compile time, ensuring consistent build metadata. Additionally, the README has been updated to include necessary import statements for the logger and tracing examples, while removing outdated and incomplete file tree documentation.

_crates/router\env · high confidence

The router now includes utility functions to validate card testing guard checks during the payments eligibility flow. This implementation generates a secure fingerprint of the card number using HMAC-SHA512 and extracts the client IP address from browser information. It then evaluates specific blocking configurations—such as card-IP blocking, guest user card blocking, customer ID blocking, and guest IP blocking—against the business profile settings, returning the necessary cache keys to enforce these restrictions.

_crates/router/src/core/card\_testing\guard · high confidence

The router now consolidates hardcoded configuration values into dedicated constant modules (\oidc.rs\, \user.rs\, \user\_role.rs\, \opensearch.rs\). This change defines specific timeouts and prefixes for OIDC tokens (e.g., 5-minute auth code TTL, 1-hour access token TTL), enforces user security policies (12-character minimum password length, 6-digit TOTP codes with 4-attempt limits), establishes standard user role identifiers (including new recon-specific roles), and configures the set of nine OpenSearch indexes available for global search.

crates/router/src/consts · high confidence

The system now uses a centralized configuration module to define which fields are required for specific payment methods, connectors, and mandate types. This change introduces structured settings for mandate support (listing supported payment methods, types, and connectors for mandates and updates) and installment eligibility (mapping connectors to supported currencies). It also defines the schema for required fields (common, mandate, and non-mandate) and bank redirect configurations, allowing these constraints to be managed declaratively rather than hardcoded in logic.

_crates/payment\methods/src/configs · high confidence

The payment method migration logic has been consolidated into a new dedicated file \crates/payment\_methods/src/core/migration/payment\_methods.rs\. This change introduces a unified \migrate\_payment\_method\ function that handles the migration workflow, including specific validation for card data (such as BIN lookup and network token handling) and a separate path for non-card payment methods like ACH or wallets. This centralization simplifies the migration process by keeping all related migration code within the payment methods crate rather than scattering it across the router or core modules.

_crates/payment\methods/src/core/migration · high confidence

The router now sets the thread stack size to 11 MiB for debug builds via a new build script, which helps prevent stack overflow errors during development. This change also integrates the \vergen\ feature to generate build-time instructions when enabled.

crates/router · high confidence

The connector template has been updated to align with the new hyperswitch\_domain\_models and hyperswitch\_interfaces architecture. The template now uses \ConnectorError\ instead of \ValidateError\ for error handling, implements the \ConnectorCommonExt\ trait for header building, and utilizes the new \RouterData\ and \AmountConvertor\ types for request/response transformation. Additionally, the test suite (\test.rs\) has been expanded to include default integration tests for card payments, covering authorization, capture, partial capture, sync, void, and refund flows for both manual and automatic capture methods.

connector-template · high confidence

This update refines the v2 database schema by removing legacy v1 columns from tables such as \merchant\_account\, \payment\_intent\, and \payment\_attempt\ to reduce storage and complexity. It also removes the \client\_secret\ column from \payment\_intent\ and the \is\_pre\_network\_tokenization\_enabled\ column from \business\_profile\. To support new data structures, a \customer\_id\ column is added to the \customers\ table, and the \customer\_id\ column in \payment\_methods\ is made nullable. Additionally, the primary key constraint on \payment\_methods\ is dropped, and new concurrent indexes are created on \payment\_methods\ (for \locker\_fingerprint\_id\) and \customers\ (for \merchant\_id\ and \merchant\_reference\_id\) to improve query performance.

_v2\migrations · high confidence

This release applies a batch of database migrations that enhance the payment and mandate data models. Key changes include adding \mandate\_id\ and \browser\_info\ to the \payment\_attempt\ table, introducing \single\_use\ amount and currency fields to the \mandate\ table, and adding \metadata\ columns to \merchant\_connector\_account\ and \merchant\_account\. The schema also standardizes identifiers by renaming \txn\_id\ to \attempt\_id\ across \payment\_attempt\ and \connector\_response\, and expands numeric precision by converting amount columns in \payment\_attempt\, \payment\_intent\, \mandate\, and \refund\ from integer to bigint. Additionally, a new \api\_keys\ table is created for key management, and various VARCHAR columns are resized to optimize storage.

migrations · high confidence

This update applies a series of database migrations to the v2-compatible schema, introducing support for new capabilities and refactoring existing structures. Key additions include columns for external vault integration (is\_external\_vault\_enabled, external\_vault\_connector\_details, external\_vault\_source, external\_vault\_token\_data) on business profiles and payment methods, enabling external vault connectors. It adds split transaction support via split\_txns\_enabled columns on payment\_intent and business\_profile, and introduces revenue recovery retry statistics with a new revenue\_recovery\_retry\_stats table and related algorithm columns in business\_profile. The schema also adds a tokenization table and flag, network error info columns to payment\_attempt, and an amount\_captured column. Structural changes include converting primary keys to VARCHAR IDs for payment\_intent, payment\_attempt, and payment\_methods, dropping NOT NULL constraints on legacy v1 columns to allow nulls during migration, and creating various indexes (including unique and partial indexes) to optimize query performance and data integrity for the new schema.

_v2\_compatible\migrations · high confidence

The router now includes a default configuration for required fields across various payout payment methods and connectors. This new \payout\_required\_fields.rs\ file defines mandatory billing details (such as address lines, city, country, and first name for specific transfers) and card fields for connectors like Adyen Platform, Ebanx, Santander, Wise, Gigadat, and Loonio. Users relying on these payout flows will now have these fields automatically validated and presented according to the specific connector's requirements without needing manual configuration overrides.

crates/router/src/configs/defaults · high confidence

The project now prevents the use of raw system clocks, entropy sources, and non-deterministic identifiers in application code by adding a \.clippy.toml\ configuration. This configuration disallows methods such as \time::OffsetDateTime::now\_utc\, \chrono::Utc::now\, \std::time::SystemTime::now\, \uuid::Uuid::new\_v4\, \uuid::Uuid::now\_v7\, \rand::thread\_rng\, \rand::random\, \nanoid::nanoid\, \std::process::id\, and \gethostname::gethostname\. Developers must instead use the instrumented functions provided in \common\_utils\ (e.g., \common\_utils::date\_time\, \common\_utils::generate\_uuid\_v4\, \common\_utils::generate\_random\_alphanumeric\_string\, \common\_utils::process\_id\, \common\_utils::hostname\) to ensure that clock and entropy reads can be reproduced during replay scenarios.

(repo-wide) · high confidence

The 3DS decision rule engine now enforces Strong Customer Authentication (SCA) mandates by overriding 'NoThreeDs' decisions to 'NoPreference' when both the issuer and acquirer are located in SCA-regulated countries, and forces a 'ChallengeRequested' decision for exemption preferences outside these regions. Additionally, the engine now accepts extended routing inputs, including card discovery status, extended card bins, and surcharge amounts, allowing for more granular decision logic based on these specific transaction attributes.

_crates/router/src/core/three\_ds\_decision\rule · high confidence

The role management API now enforces stricter hierarchy checks during role creation, preventing users from creating roles at an entity level (e.g., Organization) that exceeds their own scope, and validates role groups against the specific merchant product type. Additionally, role retrieval endpoints have been updated to return structured group and resource information, including new response types for permission groups and parent group details, improving clarity for clients managing user permissions.

_crates/router/src/core/user\role · high confidence

The router now supports granular execution paths for payments routed through the Unified Connector Service. New gateway implementations (access\_token, authorize, capture, cancel, complete\_authorize, create\_customer, and authenticate) explicitly route requests via the UCS gRPC client when the execution path is set to UnifiedConnectorService or ShadowUnifiedConnectorService, while falling back to the DirectGateway for direct connector calls. This change introduces a RouterGatewayContext that carries execution metadata (primary/shadow mode, lineage IDs, and connector account details) to enable precise routing and observability for UCS-based payment operations.

crates/router/src/core/payments/gateway · high confidence

The incoming webhook processing logic has been refactored to support a new gateway-based architecture that routes events through the Unified Connector Service (UCS) before falling back to direct connector handling. This change introduces a \WebhookGateway\ abstraction that classifies webhooks via a UCS \ParseEvent\ call, enabling UCS-only connectors to process events natively while maintaining backward compatibility for existing direct flows. The new implementation also includes dedicated modules for v2 incoming webhooks, network tokenization webhooks, and revenue recovery webhooks, ensuring that source verification, event filtering, and payload decoding are handled consistently across all webhook types.

crates/router/src/core/webhooks · high confidence

The router now uses dedicated operation structs (\FraudCheckPost\, \FraudCheckPre\, and \FraudCheckPrePayout\) to manage fraud check workflows. This change standardizes how pre-transaction, post-transaction, and pre-payout fraud checks are executed, ensuring consistent data retrieval, connector communication, and database updates for fraud records across these distinct payment flows.

_crates/router/src/core/fraud\check/operation · high confidence

This change adds new domain type definitions in the router's \types/domain\ module for core entities including Address, Event, User, and Role. These types implement conversion logic to and from the underlying Diesel storage models, ensuring that sensitive fields (such as address lines, email, and user credentials) are encrypted before persistence and decrypted upon retrieval. The Event domain type also introduces logic to resolve delivery success status based on the API context (list initial events vs. list delivery attempts), while the User domain type enforces stricter validation for names and emails.

crates/router/src/types/domain · high confidence

The router now uses a type-state pattern to track which configuration dimensions (such as provider merchant ID, processor merchant ID, organization ID, profile ID, connector, payout retry type, and webhook event) are available at any given time. This change ensures that configuration lookups only proceed when the necessary context is present, preventing runtime errors and making the configuration resolution logic more robust and predictable for merchants.

crates/router/src/core/configs · high confidence

The loadtest environment has been significantly updated to support more comprehensive performance benchmarking. The configuration file was migrated from a single \\[database\]\ section to distinct \\[master\_database\]\, \\[accounts\_database\]\, and \\[global\_database\]\ sections, and the startup command now references \development.toml\ instead of \Development.toml\. The Dockerfile was updated to use the \rust:latest\ base image, and the docker-compose setup now exposes Grafana on port 3002 and the router on port 8080. New k6 scripts (\payment-create-and-confirm.js\ and \rps.js\) were added to measure payment creation and confirmation throughput, utilizing a new \random\_string\ helper for unique customer IDs. The merchant setup script was simplified to use single-connector routing (Checkout/Stripe) instead of complex custom routing rules, and the README was updated to reflect the new Grafana port and baseline comparison workflow.

loadtest · high confidence

The nix/modules/flake directory now includes four new Nix flake modules that define the development environment and local service dependencies. devshell.nix provides three distinct development shells (default, dev, and qa) with specific tooling such as diesel-cli, cargo-watch, and cypress. rust.nix configures the Rust toolchain version (1.88.0) via rust-flake. services.nix sets up local Redis and Postgres instances using process-compose-flake, automatically creating the database and user based on the development.toml configuration. git-hooks.nix enables nixpkgs-fmt for pre-commit formatting.

nix/modules/flake · high confidence

This change introduces several new domain enums in the \common\_enums\ crate to support updated merchant account hierarchies and payment link styling. It defines \MerchantAccountType\ (Standard, Platform, Connected) and \OrganizationType\ (Standard, Platform) to distinguish between different account scopes and organizational structures. It also adds \MerchantIntegrationType\ to control \X-Integration-Type\ header validation (Client, Server, or Any) and \MerchantProductType\ to specify product capabilities like Orchestration or Vault. For payment links, it introduces \PaymentLinkDetailsLayout\ (Layout1, Layout2) and \ElementSize\ (supporting pixels, percentages, and cover/contain variants) to allow users to customize the visual appearance and layout of payment link details sections.

_crates/common\enums/src/enums · high confidence

This change introduces two new modules, \helpers.rs\ and \transformers.rs\, within the routing core. The helpers module provides functions to manage merchant default routing configurations and routing dictionaries in the database, including retrieval, creation, and updates. The transformers module implements conversion traits to map internal routing algorithm models (such as \RoutingAlgorithm\ and \RoutingProfileMetadata\) to API models (\RoutingDictionaryRecord\, \MerchantRoutingAlgorithm\), and handles the construction of requests for the Open Router service for success-rate and debit routing scenarios.

crates/router/src/core/routing · high confidence

The API models now include new data structures for bank debit and bank redirect additional information (such as ACH, BACS, SEPA, and Bancontact details) and define recipient account types for account-funded transactions, including masked views for safe API responses. Additionally, a validation rule has been added to the \PaymentsRequest\ to ensure that \request\_extended\_authorization\ is only permitted when the capture method is set to \Manual\ or \ManualMultiple\.

_crates/api\models/src/payments · high confidence

The payment link initiation flow has been restructured into distinct frontend files (payment\_link.css, payment\_link.html, payment\_link.js, and separate initiator scripts) to improve maintainability and performance. This change introduces a shimmer loading state for the payment details, implements a secure payment link initiator that enforces iframe-only rendering and uses top-level redirections, and exposes granular configuration options for the SDK UI such as custom themes, layout types (accordion/tabs), saved payment method toggles, and card nickname field visibility. Users will experience a more responsive checkout interface with better visual feedback during loading and enhanced customization capabilities for merchants.

_crates/router/src/core/payment\_link/payment\_link\initiate · high confidence

Payment links now render UI text in multiple languages (including English, Hebrew, French, Arabic, Japanese, German, and others) based on the user's locale, and enforce stricter security by validating that requests originate from allowed domains via the \sec-fetch-dest\ and \origin\/\referer\ headers.

_crates/router/src/core/payment\link · high confidence

The payment link status page has been completely rewritten to support embedded (iframed) contexts, where it now emits payment status updates to the parent window via postMessage and conditionally renders the UI based on the payment state. The new interface features a responsive design with merchant branding (logo and color scheme), localized error and status messages, and configurable redirection delays. This change also introduces structured logging for redirection events and sanitizes embedded payment data to ensure security and consistency across different display environments.

_crates/router/src/core/payment\_link/payment\_link\status · high confidence

The \redis\_interface\ crate has been refactored to allow selecting the underlying Redis client library at compile time via Cargo features. By default, the \redis-rs\ crate is used, but enabling the \fred\ feature switches the implementation to the \fred\ library. This change introduces a unified public API (\RedisConnectionPool\, \RedisSettings\, etc.) that remains consistent regardless of the chosen backend, while backend-specific modules (\module::redis\_rs\ and \module::fred\) handle the actual client interactions. The crate now includes dedicated error types (\RedisError\), constants for Redis commands, and metrics instrumentation that tracks individual roundtrips for both backends. Configuration settings in \RedisSettings\ have been expanded to support features like ACL authentication (username/password), cluster URLs, and unresponsive timeouts, with validation logic ensuring correct configuration for the selected backend.

_crates/redis\interface/src · high confidence

This change refactors the \hyperswitch\_domain\_models\ crate to improve type safety and separation of concerns. It introduces concrete types for \payment\_method\ and \payment\_method\_type\ fields, replacing previous generic or string-based representations, and switches the \payment\_method\_data\ field to use a concrete type. Additionally, conversion implementations for customer, payment methods, merchant accounts, business profiles, and payment attempts are moved from the domain models into the \storage\_impl\ crate, decoupling storage logic from the core domain definitions.

_crates/hyperswitch\_domain\models · high confidence

The scheduler's retry configuration has been consolidated into a unified \RetryMapping\ struct that stores frequency and count as a single vector of tuples, replacing the previous separate fields. New default retry schedules are now defined for subscription invoice syncs, payment methods, outgoing webhooks, and revenue recovery payments. Additionally, the \ProcessTrackerBatch\ deserialization logic was refactored to use \error\_stack\'s \ResultExt\ directly, removing redundant \into\_report()\ calls and simplifying error handling during batch processing.

crates/scheduler/src/consumer/types · high confidence

The router's HTTP client implementation has been refactored to simplify construction and improve security. The custom \Request\ and \RequestBuilder\ structs previously defined in this module have been removed and replaced with implementations from the \hyperswitch\_interfaces\ crate, which now handles request building via the \ApiClient\ trait. Proxy configuration no longer relies on environment variables (\ROUTER\_HTTP\_PROXY\, \ROUTER\_HTTPS\_PROXY\); instead, it uses a dedicated \ProxyClient\ that respects configuration settings and supports optional mTLS client certificates for secure connector communication. Additionally, header handling now supports masking sensitive values directly within the request builder.

crates/router/src/services/api · high confidence

The card and payment method tokenization logic in the router has been restructured to use a new state-machine pattern. New files \card\_executor.rs\ and \payment\_method\_executor.rs\ define explicit states (e.g., \TokenizeWithCard\, \CardRequestValidated\, \CardTokenized\) and transitions for the tokenization process. This change replaces the previous linear implementation with a builder-based approach that validates requests, assigns customer and card details, handles network tokenization, and stores tokens in a more modular and traceable way. Users benefit from more robust error handling and clearer separation of concerns during the tokenization flow.

_crates/router/src/core/payment\methods/tokenize · high confidence

The router's error handling has been restructured to replace the monolithic \ApiErrorResponse\ enum with domain-specific error types (such as \CustomersErrorResponse\, \UserErrors\, \OidcErrors\, and \LaunchSageErrors\) that map to the unified \ApiErrorResponse\ via a new \ErrorSwitch\ trait. This change introduces RFC 6749-compliant error codes for OIDC flows, adds specific error variants for user management (including 2FA, themes, and sample data), and standardizes HTTP status code mapping across the system, resulting in more precise and consistent API error responses for customers, users, and authentication services.

crates/router/src/core/errors · high confidence

The mandate handling logic in the router core has been reorganized into two new files, \helpers.rs\ and \utils.rs\. \helpers.rs\ introduces a \get\_profile\_id\_for\_mandate\ function to resolve profile IDs from payment intents and a \get\_mandate\_type\ function that determines mandate transaction types based on inputs like \off\_session\ flags and \customer\_acceptance\. \utils.rs\ adds a \construct\_mandate\_revoke\_router\_data\ function to build the necessary router data structures specifically for mandate revocation flows, ensuring consistent data population for connector interactions.

crates/router/src/core/mandate · high confidence

The file \crates/router/src/connector/adyen/transformers.rs\ has been deleted, removing the local definitions for Adyen payment, cancel, and refund request and response structs (such as \AdyenPaymentRequest\, \AdyenPaymentResponse\, \AdyenCancelRequest\, and \AdyenRefundRequest\) along with their \TryFrom\ transformation implementations. This change indicates that the data structures and serialization logic for communicating with the Adyen connector have been moved to a different location or module within the codebase.

crates/router/src/connector/adyen · high confidence

The feature flags for the v2 payment methods and customer APIs have been removed, indicating that these capabilities are now generally available and no longer gated behind experimental toggles. Users can rely on the v2 endpoints for managing customer payment methods and customer profiles as standard, stable API contracts.

_crates/api\models/src, crates/router/src, crates/router/src/core · high confidence

The \transformers.rs\ file for the ACI connector has been deleted, removing the legacy implementation for mapping payment requests and responses. This eliminates the previous logic for handling card, bank transfer, and PayLater payment methods via the \AciPaymentsRequest\ and \AciPaymentsResponse\ structs, indicating a structural refactor or replacement of the ACI connector integration.

crates/router/src/connector/aci · high confidence

The \transformers.rs\ file in the Stripe connector module has been deleted. This file previously contained the logic for mapping internal payment data structures to Stripe's specific API request formats, including handling card, Klarna, and bank transfer payment methods. Its removal indicates a refactoring of the connector integration, likely moving this transformation logic to a different location or a new architectural pattern within the router.

crates/router/src/connector/stripe · high confidence

The \payment\_methods\_v2\ and \customer\_v2\ feature flags have been removed from the router core. This change finalizes the migration to the v2 implementations, meaning these capabilities are now permanently enabled and the conditional code paths guarded by these flags are no longer present in the payment processing flow.

crates/router/src/core/payments · high confidence

The scheduler module has removed several internal type definitions that are no longer used: \SchedulerConfig\, \SchedulerOptions\, \ReadinessOptions\, \ProcessData\, \RetryMapping\, \ConnectorPTMapping\, \WorkflowState\, and \DummyWorkflowState\. This cleanup eliminates unused configuration structures, retry mapping logic, and placeholder state types from the scheduler's public API surface.

crates/router/src/scheduler/types · high confidence

The logging subsystem in \crates/router\_env\ has been refactored to improve configuration flexibility and code clarity. Default logging settings (file and console) are now defined in Rust code (\defaults.rs\) rather than a TOML file, and the configuration structs now implement \Default\ with \\#\[serde(default)\]\ to simplify initialization. The configuration loading logic has been updated to use \serde\_path\_to\_error\ for more descriptive error messages when parsing fails, and the config file is no longer strictly required. Additionally, the \FormattingLayer\ now accepts a generic formatter, and the \setup\ function has been streamlined to better separate trace, metric, and log layer initialization.

_crates/router\env/src/logger · high confidence

The revenue recovery workflow now supports multiple retry algorithms, including an adaptive scheduler that determines the next retry time based on payment outcomes rather than a fixed ladder. This change introduces persistent storage for retry statistics, allowing the system to track and learn from past attempts. Additionally, the recovery flow now includes Redis-based token tracking to manage payment processor tokens more effectively, and supports updating additional card information from CSV data. These enhancements aim to improve the success rate of recovering passive churn payments by making retry decisions more intelligent and data-driven.

_crates/router/src/core/revenue\recovery · high confidence

The router's configuration handling has been migrated from a TOML-based approach to a strongly-typed Rust implementation. Default values previously defined in \defaults.toml\ are now hardcoded in \defaults.rs\, and comprehensive validation logic has been added in \validations.rs\ to ensure critical settings (such as database credentials, server hosts, and API keys) are not empty or invalid at startup. Additionally, \secrets\_transformers.rs\ introduces a structured mechanism for resolving encrypted secrets (like database passwords and API keys) via a secrets management client, replacing the previous inline decryption logic.

crates/router/src/configs · high confidence

The API now returns a consistent error format for all HTTP responses, including a JSON body with fields for error type, message, and a zero-padded error code (e.g., IR\_04). This change introduces a new error model in \crates/api\_models/src/errors\ that maps internal error variants to specific HTTP status codes (such as 400, 401, 403, 404, 409, 422, 500) and ensures the \Content-Type\ is set to \application/json\. Users will see structured error details in the response body for all API failures, improving debugging and integration reliability.

_crates/api\models/src/errors · high confidence

The Stripe compatibility layer for customer operations has been updated to use new internal types for address details and secret masking. Address fields (line1, line2, postal\_code, state) now utilize \hyperswitch\_masking::Secret\ for enhanced data protection, and the \Shipping\ struct has been introduced to handle shipping information. Customer request and response models have been adjusted to align with these changes, including the use of \id\_type::CustomerId\ for IDs and \pii::SecretSerdeValue\ for metadata, ensuring consistent handling of sensitive customer data in the Stripe API compatibility layer.

crates/router/src/compatibility/stripe/customers · high confidence

The Stripe compatibility module now exposes Setup Intents, Webhooks, and Mandates endpoints alongside the existing Payment Intents, Refunds, and Customers, allowing users to manage the full lifecycle of Stripe-compatible payments including setup flows and recurring mandates. The underlying API wrapper has been refactored to support a richer set of response types (including JSON with headers, file data, and generic/payment link forms) and integrates with the new events framework for logging, providing more detailed observability and support for complex redirection scenarios.

crates/router/src/compatibility · high confidence

The Stripe compatibility layer in the router now supports Wallet, UPI, Bank Redirect, and Real Time Payment methods in addition to Cards, mapping these new types to the core payment method enum. Request and response structures have been updated to use specific domain types (e.g., \Email\, \CardNumber\) and masking strategies for sensitive fields like card details and UPI VPAs, improving data integrity and security. The billing details mapping has been refined to correctly extract country codes from address data, and the card object now supports optional holder names and exposes additional card metadata fields.

_crates/router/src/compatibility/stripe/payment\intents · high confidence

The Stripe compatibility layer for refunds has been updated to allow updating refund metadata via a new \StripeUpdateRefundRequest\ type, enabling users to modify metadata on existing refunds. Additionally, the \StripeCreateRefundRequest\ now accepts optional \refund\_id\, \metadata\, and \merchant\_connector\_details\ fields, while the \StripeRefundResponse\ exposes additional fields including \created\ timestamp and \metadata\. These changes align the Stripe-compatible refund API with more granular control and richer data exposure for users interacting with the router via Stripe's interface.

crates/router/src/compatibility/stripe/refunds · high confidence

Add ACI connector test suite to Postman collection; Added UI tests for multiple payment connectors; Added connector integration tests for multiple payment providers; Added regression test for ingress recording circular dependency; Added tests for Percentage type validation and deserialization; Added tests for card security code and expiration validation; Added tests for the \ApplyChangeset\ derive macro; Expanded integration test coverage for router components; Removed basic masking tests.

The router and scheduler binaries now use the \clap\ crate for command-line argument parsing instead of the deprecated \structopt\ library. Additionally, when the \gcp\_kms\ feature is enabled, the application explicitly installs the \aws-lc-rs\ TLS crypto provider as the default, resolving potential conflicts with other AWS SDK dependencies that also require a TLS backend. This ensures consistent cryptographic behavior and removes the dependency on the unmaintained \structopt\ crate.

crates/router/src/bin · high confidence

A new \analytics\ crate has been introduced to handle analytics, reports, and search functionality. This addition brings in dependencies on \opensearch\ (v2.3.0) for search capabilities and \aws-sdk-lambda\ (v1.60.0) for serverless integration, alongside standard internal framework crates like \api\_models\, \diesel\_models\, and \storage\_impl\.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 36 → 40 (+4.3)
• Rubric changed (rubric-2026.08.15 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 51 → 59 (+8.4)
• Architecture 69 → 85 (+16.4)
• Maturity 62 → 79 (+17.3)
• Readiness 19 → 51 (+31.5)
• Security 44 → 41 (-3.4)
• Domain Modelling 85 (new)
• Event Sourcing 100 (new)
• Accessibility 25 (new)

• Change coupling: commands.js ↔ RequestBodyUtils.js (cypress-tests/cypress/support/commands.js)
• Change coupling: commands.js ↔ e2e.js (cypress-tests/cypress/support/commands.js)
• Change coupling: cypress.config.js ↔ commands.js (cypress-tests/cypress.config.js)
• Change coupling: cypress.config.js ↔ e2e.js (cypress-tests/cypress.config.js)
• Change coupling: imports.js ↔ commands.js (cypress-tests/cypress/fixtures/imports.js)
• Change coupling: payment_link_initiator.js ↔ secure_payment_link_initiator.js (crates/router/src/core/payment_link/payment_link_initiate/payment_link_initiator.js)
• Critical CVE: [GHSA redacted] (package-lock.json)
• Critical CVE: [GHSA redacted] (Cargo.lock)
• Critical CVE: [GHSA redacted] (cypress-tests-v2/package-lock.json)
• Critical CVE: [GHSA redacted] (Cargo.lock)
• Critical CVE: [GHSA redacted] (Cargo.lock)
• Dimension evaluation failed
• FileTooLong: dashboard/dashboard.js (cypress-tests/dashboard/dashboard.js)
• FileTooLong: support/commands.js (cypress-tests-v2/cypress/support/commands.js)
• FileTooLong: support/commands.js (cypress-tests/cypress/support/commands.js)
• FileTooLong: support/redirectionHandler.js (cypress-tests/cypress/support/redirectionHandler.js)
• High CVE: [GHSA redacted] (cypress-tests-v2/package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (Cargo.lock)
• High CVE: [GHSA redacted] (cypress-tests-v2/package-lock.json)
• …and 126 more

• Aci::get_webhook_event_type (cognitive 18) (crates/hyperswitch_connectors/src/connectors/aci.rs)
• AdyenPaymentMethod::try_from (cyclomatic 23) (crates/hyperswitch_connectors/src/connectors/adyen/transformers.rs)
• AdyenWebhookResponse::from (cognitive 21) (crates/hyperswitch_connectors/src/connectors/adyen/transformers.rs)
• AdyenWebhookResponse::from (cyclomatic 19) (crates/hyperswitch_connectors/src/connectors/adyen/transformers.rs)
• AirwallexPaymentsRequest::try_from (cognitive 17) (crates/hyperswitch_connectors/src/connectors/airwallex/transformers.rs)
• AirwallexPaymentsRequest::try_from (cyclomatic 18) (crates/hyperswitch_connectors/src/connectors/airwallex/transformers.rs)
• AuthEventFilterRow::from_row (cognitive 28) (crates/analytics/src/sqlx.rs)
• AuthEventFilterRow::from_row (cyclomatic 29) (crates/analytics/src/sqlx.rs)
• AuthEventFilters::set_filter_clause (cognitive 22) (crates/analytics/src/auth_events/types.rs)
• AuthEventFilters::set_filter_clause (cyclomatic 23) (crates/analytics/src/auth_events/types.rs)
• AuthEventMetricRow::from_row (cognitive 29) (crates/analytics/src/sqlx.rs)
• AuthEventMetricRow::from_row (cyclomatic 30) (crates/analytics/src/sqlx.rs)
• AuthipayPaymentsResponse::get_transaction_status (cyclomatic 21) (crates/hyperswitch_connectors/src/connectors/authipay/transformers.rs)
• Authorize::execute (cognitive 21) (crates/router/src/core/payments/gateway/authorize_gateway.rs)
• BackwardCompatWorkflowBuilder::backfill_legacy_locker_card (cognitive 17) (crates/router/src/workflows/payment_method_modular_backward_compat.rs)
• BackwardCompatWorkflowBuilder::backfill_legacy_locker_card (cognitive 18) (crates/router/src/workflows/payment_method_modular_backward_compat.rs)
• BankOfAmericaPaymentsRequest::try_from (cognitive 20) (crates/hyperswitch_connectors/src/connectors/bankofamerica/transformers.rs)
• BraintreePaymentsRequest::try_from (cognitive 54) (crates/hyperswitch_connectors/src/connectors/braintree/transformers.rs)
• BraintreePaymentsRequest::try_from (cyclomatic 23) (crates/hyperswitch_connectors/src/connectors/braintree/transformers.rs)
• Change coupling clique: payment_intent.rs, payment_intent.rs, payment_intent_event.rs (crates/hyperswitch_domain_models/src/payments/payment_intent.rs)
• …and 8874 more

• 300 commits — 209 feature/other, 91 fixes

• crates/router — 116 commits
• crates/hyperswitch_connectors — 38 commits
• (root) — 36 commits
• cypress-tests/cypress — 35 commits
• config/deployments — 20 commits
• crates/api_models — 9 commits
• crates/connector_configs — 4 commits
• crates/diesel_models — 4 commits
• crates/hyperswitch_domain_models — 4 commits
• .github/workflows — 3 commits
• crates/openapi — 3 commits
• crates/payment_methods — 3 commits
• crates/storage_impl — 3 commits
• api-reference/v1 — 2 commits
• api-reference/v2 — 2 commits
• config/superposition_seed.toml — 2 commits
• crates/common_utils — 2 commits
• crates/external_services — 2 commits
• crates/hyperswitch_interfaces — 2 commits
• crates/analytics — 1 commit

• fix: Revert: "fix(connector): [CYBERSOURCE] Commerce Indicator Mapping For Externally Authenticated Transactions" (#13806)
• fix: ci(cypress): Fix zero auth mandate test for stripe connect (#14387)
• fix: ci(cypress): fix datatrans and fiuu connector tests (#13885)
• fix: ci(cypress): fix hipay connector configs (#14334)
• fix: ci(cypress): fix payu cypress tests (#14385)
• fix: ci(cypress): fix tsys transit connector tests and superposition api (#14290)
• fix: ci(cypress): fix wellsfargo connector and add stripe dispute accept (#13901)
• fix: fix(NMI): [NMI] add PR and LB for card allowed countries payment (#13773)
• fix: fix(authentication): added highest common supported version for 3ds server (#14305)
• fix: fix(authentication): made threeds requestor id as necessary field for juspayThreeDS server (#14041)
• fix: fix(checkout): send external 3DS authentication data to connector for no_3ds payments (#13776)
• fix: fix(config): add France to worldpayxml payment method filters (#13753)
• fix: fix(config): route ilixium through UCS in sandbox and production (#13841)
• fix: fix(configs): [tsys_transit] add mandate config (#13826)
• fix: fix(connector): [Adyen] Fix RefundedReversed Parsing (#13601)
• fix: fix(connector): [CYBERSOURCE] Commerce Indicator Mapping For Externally Authenticated Transactions (#13527)
• fix: fix(connector): [CYBERSOURCE] Commerce Indicator for Setup Mandate Externally Authenticated Transactions (#13838)
• fix: fix(connector): [GOCARDLESS] parse webhook action and links by resource_type (#14239)
• fix: fix(connector): [Payshield] Use payment attempt creation time for FRM requests (#14190)
• fix: fix(connector): [Peachpayments] Fix Setup Mandate Endpoint (#13734)
• …and 280 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

juspay/hyperswitch was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.