Skip to content

Class Name: StripeHttpCalloutMock

Last Updated: 2025-10-22 Source Code: StripeHttpCalloutMock.cls

API Name: StripeHttpCalloutMock Type: Test Test Coverage: N/A (Test Utility Class) Author: Ecaterina Popa Created: 06/26/2024

Business Purpose

This test utility class provides mock HTTP responses for Stripe payment API testing, enabling reliable unit testing of payment processing functionality without making actual API calls or incurring transaction costs. It supports AANP's e-commerce testing infrastructure by simulating various payment scenarios.

Class Overview

Scope and Sharing

  • Sharing Model: Not applicable (@IsTest class)
  • Access Modifier: global
  • Interfaces Implemented: HttpCalloutMock (through inner classes)

Key Responsibilities

  • Provide mock responses for successful Stripe payment operations
  • Simulate card decline and error scenarios
  • Support testing of tokenization, authorization, capture, and refund operations
  • Return appropriate HTTP status codes and JSON payloads

Public Methods

Inner Classes

MockSuccess

public class MockSuccess implements HttpCalloutMock

Purpose: Simulates successful Stripe API responses for all payment operations.

respond Method: - Returns HTTP 200 status code - Detects endpoint type from URL - Returns appropriate JSON response structure

Supported Endpoints: - /charges - Returns {"amount": 10000} - /capture - Returns charge capture response with balance_transaction and receipt_url - /tokens - Returns {"id": "token"} - /customers - Returns customer object with id and default_source - /refunds - Returns refund object with status "succeeded"

Usage Example: 

Test.setMock(HttpCalloutMock.class, new StripeHttpCalloutMock.MockSuccess());

MockErrorUnknownCode

public class MockErrorUnknownCode implements HttpCalloutMock

Purpose: Simulates Stripe API errors with unknown/unhandled error codes.

respond Method: - Returns HTTP 400 status code - Returns error object with type "unknown_error" - Error code "404" with decline code "404" - Error message "Card Error"

Usage Example: 

Test.setMock(HttpCalloutMock.class, new StripeHttpCalloutMock.MockErrorUnknownCode());

Business Logic: - Used to test error handling for unexpected Stripe responses - Should trigger GatewayErrorResponse in StripeAdapter

MockErrorKnownCode

public class MockErrorKnownCode implements HttpCalloutMock

Purpose: Simulates Stripe API card errors with known decline codes.

respond Method: - Returns HTTP 400 status code - Detects endpoint type (charges or tokens) - Returns error object with type "card_error" - Error code "card_not_supported" (one of the DECLINE_CODES in StripeAdapter) - Decline code "404" and message "Card Error"

Usage Example: 

Test.setMock(HttpCalloutMock.class, new StripeHttpCalloutMock.MockErrorKnownCode());

Business Logic: - Tests handling of known card decline scenarios - Should trigger specific decline handling in StripeAdapter - Maps to Salesforce SalesforceResultCode.Decline

Private/Helper Methods

This class contains no private methods - all logic is within the inner class respond methods.

Dependencies

Apex Classes

  • HttpCalloutMock: Salesforce interface for HTTP mocking
  • HttpRequest: Request object analyzed in respond methods
  • HttpResponse: Response object returned by mocks

Salesforce Objects

  • None (test utility class)

Custom Settings/Metadata

  • None

External Services

  • None (mocks external services, does not call them)

Design Patterns

  • Mock Object Pattern: Provides test doubles for HTTP callouts
  • Strategy Pattern: Different mock classes for different test scenarios
  • Factory Pattern: Inner classes provide different mock implementations

Governor Limits Considerations

SOQL Queries: None DML Operations: None CPU Time: Minimal - simple string operations Heap Size: Minimal - small JSON strings

Bulkification: N/A (test utility) Async Processing: N/A (test utility)

Error Handling

Strategy: Returns error responses as part of normal mock behavior Logging: None (test utility) User Notifications: N/A (test utility)

Security Considerations

Sharing Rules: N/A (@IsTest class) Field-Level Security: N/A (no database operations) CRUD Permissions: N/A (no database operations) Input Validation: Minimal - only checks request endpoint URLs

Test Class

Test Class: This IS a test utility class used by StripeAdapterTest.cls Coverage: N/A Usage: - Used in StripeAdapterTest to simulate Stripe API responses - Supports testing of StripeAdapter payment operations

Changes & History

  • 2024-06-26: Initial implementation by Ecaterina Popa

Pre-Go-Live Concerns

CRITICAL - Fix Before Go-Live

  • None (test utility class)

HIGH - Address Soon After Go-Live

  • LIMITED ERROR SCENARIOS: Only supports 2 error types - consider adding more decline codes
  • HARDCODED AMOUNTS: All success responses return 10000 - consider parameterizing
  • NO PARTIAL CAPTURE MOCK: Doesn't simulate partial capture scenarios

MEDIUM - Future Enhancement

  • Add mock for additional Stripe decline codes (expired_card, insufficient_funds, etc.)
  • Support different amounts based on request parameters
  • Add mock for Stripe webhook responses if needed
  • Add mock for refund operations (currently included but not tested)
  • Parameterize response data for more flexible testing

LOW - Monitor

  • Keep mock responses aligned with Stripe API version used by StripeAdapter
  • Review Stripe API changelog for response structure changes
  • Ensure test scenarios cover all critical payment paths

Maintenance Notes

Complexity: Low Recommended Review Schedule: Annually (or when Stripe API changes) Key Maintainer Notes: - This mock class must stay synchronized with StripeAdapter implementation - When adding new Stripe API endpoints to StripeAdapter, add corresponding mocks here - Test amounts are hardcoded as 10000 (representing $100.00 for USD) - The DECLINE_CODES list in StripeAdapter determines which error codes are "known" - MockErrorKnownCode uses "card_not_supported" which is in the DECLINE_CODES list - If Stripe API response structure changes, update mock JSON accordingly - When testing new payment scenarios, may need to add new mock classes - Consider extracting test data as constants if mock responses become more complex