ITADN

[FEATURE] Add Fraud Service to Hyperswitch Prism

#934Openmanojradhakrishnan 创建于 2026-04-06
## Summary This issue tracks the implementation of the Fraud Service for Hyperswitch Prism, enabling unified integration with fraud detection providers (Signifyd, Riskified). ## Background The Prism library currently supports Payments, Payouts, Refunds, and Disputes. To provide comprehensive commerce coverage, we need to add Fraud detection capabilities following the same architectural patterns. ## Proposed Solution ### Service Definition Implement `FraudService` with 6 RPC methods: | Method | Purpose | Provider Mapping | |--------|---------|------------------| | `EvaluatePreAuthorization` | Pre-auth fraud check | Signifyd /checkouts, Riskified /submit or /decide | | `EvaluatePostAuthorization` | Post-auth case update | Signifyd /transactions, Riskified /update | | `RecordTransactionData` | Post-hoc transaction recording | Signifyd /sales, Riskified /create | | `RecordFulfillmentData` | Shipment notification | Signifyd /fulfillments, Riskified /fulfill | | `RecordReturnData` | Return/refund recording | Signifyd /returns, Riskified /partial_refund | | `Get` | Decision retrieval | Signifyd /decisions/{id} | ### Key Design Decisions 1. **Hyperswitch-Aligned Enums**: - `FraudCheckStatus` uses exactly 5 states from Hyperswitch: `PENDING`, `FRAUD`, `LEGIT`, `MANUAL_REVIEW`, `TRANSACTION_FAILURE` - `FraudAction` simplified to `ACCEPT`/`REJECT` only - **No new states introduced** - strict compliance with existing Hyperswitch enums 2. **Method Naming**: Clear verb-noun format for clarity - Previous names (`Checkout`, `Transaction`, `Sale`) were ambiguous - New names explicitly indicate timing and purpose 3. **Removed Cancel**: Not supported uniformly by providers - Signifyd: No explicit API (dashboard only) - Riskified: Has API but inconsistent pattern ### Implementation Phases **Phase 1: Protocol Buffers (Week 1)** - Create `fraud.proto` with Hyperswitch-aligned enums - Update `services.proto` with FraudService - Add webhook event types **Phase 2: Domain Types (Week 1-2)** - Implement `fraud_types.rs` with Hyperswitch enums - Add connector flow types **Phase 3: Interface Traits (Week 2)** - Define fraud connector traits - Implement 6 flow traits **Phase 4: Connectors (Week 3)** - Signifyd connector implementation - Riskified connector implementation **Phase 5: gRPC Service (Week 3-4)** - FraudService handler - Service registration **Phase 6-8: SDK, Testing, Documentation (Week 4-6)** ### Documentation Complete specification documents created in `docs/plans/fraud/`: | Document | Purpose | |----------|---------| | `01-fraud-interface-specification.md` | Technical specification with proto schema | | `02-implementation-plan.md` | Step-by-step implementation guide | | `03-connector-implementation-guide.md` | Developer guide for connectors | | `04-proto-validation-analysis.md` | Provider API validation | ## Acceptance Criteria - [ ] Proto schema compiles without errors - [ ] Domain types match Hyperswitch enums exactly - [ ] Signifyd connector implements all 6 flows - [ ] Riskified connector implements all 6 flows - [ ] gRPC service handles all 6 RPC methods - [ ] Integration tests pass - [ ] Documentation complete ## Related Issues N/A - New feature ## Additional Context ### Provider State Mapping All provider states map cleanly to Hyperswitch's 5 states: | Signifyd | Riskified | Hyperswitch | |----------|-----------|-------------| | ACCEPT | approved | LEGIT | | REJECT | declined/canceled | FRAUD | | REVIEW | review | MANUAL_REVIEW | | PENDING | pending | PENDING | | ERROR | gateway_error | TRANSACTION_FAILURE | ### Required Fields New fields required for provider integration: - `device_fingerprint`: Signifyd requirement for device-based analysis - `session_id`: Session correlation for both providers - `synchronous`: Riskified sync/async mode selection
0 条评论