Standardized Payment Mandate Interface for Multi-Provider Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing electronic payment systems face challenges in providing consistent payment mandate services across multiple payment providers, due to differences in implementation and lack of standardized interfaces, leading to confusing experiences for customers and increased engineering burdens for payment hubs.

Innovation Solution

The implementation of a standardized Service Provider Interface (SPI) by payment providers, allowing for uniform interactions with payment mandates, including setup, invocation, and revocation, facilitates consistent payment mandate services across different payment providers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If payment providers implement different payment mandate interfaces, then each provider can optimize for its own system, but the payment hub faces increased engineering burden and customers experience confusion

Engineering Contradiction:
ImprovePayment provider system optimizationVSAvoidPayment hub engineering complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a standardized Service Provider Interface (SPI) as an intermediary layer between the payment hub and multiple payment providers. This SPI defines uniform methods for payment mandate operations (create, invoke, revoke) that mask the underlying diversity of payment provider implementations. The payment hub interacts only with the standardized SPI, while the payment providers implement their specific logic behind this uniform interface, thus resolving the contradiction between provider optimization and hub complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The SPI is designed as a universal interface that can work with multiple different payment providers through a common set of methods. The interface defines standard operations (createPaymentMandate, invokePaymentMandate, revokePaymentMandate) that are implemented differently by each payment provider but present a unified view to the payment hub, enabling multi-functionality across diverse providers.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If payment providers use non-standardized interfaces, then implementation flexibility is maintained, but customer experience consistency deteriorates

Engineering Contradiction:
ImprovePayment provider implementation flexibilityVSAvoidCustomer experience consistency
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The SPI acts as a mediator that translates between the standardized customer-facing operations and the provider-specific implementations. Customers interact with uniform payment mandate operations regardless of which payment provider is used, while the SPI routes these operations to the appropriate provider-specific logic, maintaining both flexibility and consistency.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If custom integration is developed for each payment provider, then specific provider requirements are met, but development time and engineering resources increase

Engineering Contradiction:
ImprovePayment provider specific requirements fulfillmentVSAvoidDevelopment time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The SPI provides a universal interface that can be implemented once and used with multiple payment providers. The standard methods (createPaymentMandate, invokePaymentMandate, revokePaymentMandate) encapsulate the common functionality needed across providers, reducing development time while maintaining provider-specific requirements through the implementation details behind the interface.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS20250182114A1Payment mandates for merchant initiated transactions
Publication Date: 2025.06.05 STRIPE LLC
  • US20250182114A1 patent drawing
  • US20250182114A1 patent drawing
  • US20250182114A1 patent drawing

AI summary

A system includes: a processing circuit; and memory storing instructions that, when executed by processing devices include the processing circuit, cause the processing devices to: receive a payment mandate setup request from a merchant of a plurality of merchants; create a payment provider-independent payment mandate setup request based on the payment mandate setup request; receive a payment provider identifier identifying a payment provider from among a plurality of payment providers; transmit the payment provider-independent payment mandate setup request to the payment provider identified by the payment provider identifier, the payment provider-independent payment mandate setup request include a payment mandate identifier; receive approval of the payment mandate setup request from specified payment provider, the approval include the payment mandate identifier; and store a payment mandate for a customer of the merchant in association with the merchant and the payment provider, the payment mandate being associated with the payment mandate identifier.