Reprogrammable POS Foreground Register for Custom Transaction Flows

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing point-of-sale (POS) devices lack the ability for merchants to customize transaction flows, user interfaces, and control buyer-facing displays, limiting flexibility and consistency in customer interactions.

Innovation Solution

A payment service exposes APIs and SDKs to merchants, allowing them to modify transaction flows, user interfaces, and control buyer-facing displays through merchant applications, enabling customization and integration of payment service functionality within their own applications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If POS devices use standardized payment service interfaces, then transaction processing reliability is improved, but merchant customization capability deteriorates

Engineering Contradiction:

Improvetransaction processing reliabilityVSAvoidmerchant customization capability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system separates the payment processing functionality into independent modules that can be selectively activated. The payment service application contains discrete transaction flow steps, UI components, and control functions that can be individually customized by merchants through configuration files, allowing reliability of core payment functions while enabling customization of specific segments.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The POS device architecture enables dynamic configuration of transaction flows at runtime. Merchants can modify transaction steps, UI presentations, and buyer-facing display content through configurable parameters without changing the underlying payment processing logic, allowing the system to adapt to different merchant needs while maintaining stable core functionality.

Inventive Principle:

Principle #15Dynamics

2Productivity

If POS devices follow standardized transaction flows, then processing efficiency is improved, but merchant-specific customization deteriorates

Engineering Contradiction:

Improveprocessing efficiencyVSAvoidmerchant-specific customization

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

The system provides pre-configured transaction flow templates with standard payment processing steps that ensure efficiency. Merchants can select from predefined templates and then customize specific steps through configuration files, combining the benefits of standardized efficient processing with the ability to adapt to specific merchant requirements.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The architecture allows merchants to customize transaction flows by modifying parameters such as step sequences, UI display options, and buyer-facing display content, while the core payment processing logic remains standardized. This enables efficient standardized processing with flexible parameter-level customization.

Inventive Principle:

Principle #35Parameter changes

3Stability of the object's composition

If POS devices present standardized user interfaces, then consistency across transactions is improved, but merchant branding and customization deteriorates

Engineering Contradiction:

Improveinterface consistencyVSAvoidmerchant branding capability

Core Design Contradiction:

Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The system maintains standardized core UI components for consistent payment processing while allowing merchants to customize specific UI elements such as branding, logos, and presentation styles through configuration files. This enables local customization of merchant-specific elements while preserving the consistency of critical transaction interface components.

Inventive Principle:

Principle #3Local quality

4Device complexity

If POS devices lack application programming interfaces, then system simplicity is maintained, but merchant integration capability deteriorates

Engineering Contradiction:

Improvesystem simplicityVSAvoidmerchant integration capability

Core Design Contradiction:

Device complexityVSAdaptability or versatility

Solution Approach 1:

The payment service application acts as an intermediary layer between the standardized payment service and merchant-specific applications. It provides a configured transaction flow that can be customized through configuration files without requiring complex API integrations, maintaining system simplicity while enabling merchant integration capabilities.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS20250252411A1Reprogrammable point-of-sale foreground register marrionette

Publication Date: 2025.08.07 BLOCK INC

AI summary

Techniques and arrangements for allowing modification of transaction flows, user interfaces (UIs), receipt configuration and control of buyer-facing displays associated with transactions between a payment service, a merchant and a buyer are provided. Payment service payment functionality is exposed by the payment service via one or more application programming interfaces (API)s, software development kits (SDKs), or some other web-based communication technique (e.g., a uniform resource locator). The payment service payment functionality exposed by the payment service allows a merchant to customize one or more steps of a transaction between a user and a merchant. A merchant can use the exposed payment service payment functionality to configure and modify the look and feel and/or the steps within a transaction flow.