SDK Tap-to-Pay Automation for Mobile Payment Forms

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Users face difficulties in accurately entering long account identifiers for payment cards on computing devices, leading to errors and security risks, and conventional payment methods often result in higher processing fees and increased fraud risks due to 'card not present' transactions.

Innovation Solution

A computer-implemented method using a software development kit (SDK) that enables tap-to-pay operations on mobile devices by receiving payment information from a contactless card through NFC communication, authenticating it, and securely populating payment information into web forms, thereby reducing fraud risks and transaction fees.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If users manually enter account identifiers for payment cards, then the transaction can be processed, but errors occur and security risks increase

Engineering Contradiction:
Improveaccuracy of account identifier entryVSAvoidsecurity risks from camera capture and manual entry errors
Core Design Contradiction:
Measurement precisionVSObject-affected harmful factors

Solution Approach 1:

The patent replaces manual mechanical entry of account identifiers with automated optical recognition using a camera. The system captures an image of the payment card and automatically extracts the account identifier, eliminating manual typing errors and reducing exposure time of sensitive information.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The system creates a visual copy of the payment card through camera imaging, then extracts data from this copy rather than requiring direct manual input. This allows automated processing while maintaining security by limiting human exposure to sensitive card information.

Inventive Principle:
Principle #26Copying

2Productivity

If conventional card not present transaction methods are used, then the transaction can be completed, but processing fees increase and fraud risks increase

Engineering Contradiction:
Improvetransaction processing efficiencyVSAvoidfraud risk and transaction security
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent introduces a mobile device as an intermediary between the payment card and the merchant system. The mobile device captures the card image, extracts the account identifier, and transmits it securely, transforming a card-not-present transaction into a more secure hybrid model with reduced fraud risk and lower processing fees.

Inventive Principle:
Principle #24Intermediary (Mediator)

Applied Scientific Principles

This section explains which scientific principles are used to turn an abstract innovation direction into a practical engineering solution.

Function Achieved in This Case

The solution provides secure, automated checkout processes with minimal fraudulent activity, reduces transaction fees, and ensures that transactions are processed as 'card present' transactions, lowering risks and costs.

Implementation Method 1

receiving, by the SDK, the payment information and a cryptogram from the contactless card via wireless communications

Methodology Applied
Scientific EffectNFC communication: Electromagnetic Induction

Data Source

PatentUS20230325810A1Techniques to perform tap to pay operations in the IOS and android operating system environments
Publication Date: 2023.10.12 CAPITAL ONE SERVICES LLC
  • US20230325810A1 patent drawing
  • US20230325810A1 patent drawing
  • US20230325810A1 patent drawing

AI summary

A software development kit (SDK) in an application may receive a selection of a uniform resource locator (URL) in a form for a transaction. The SDK may present an SDK interface overlaid on the application. The SDK may receive selection of an interface element in the SDK interface. The SDK may present, in the SDK interface, orientation instructions. The SDK may receive payment information and a cryptogram from the contactless card and transmit the cryptogram to a server. The SDK may receive a result specifying the server decrypted the cryptogram and present a permissions element. The SDK may fill the payment information in one or more fields of the form and receive input specifying to process the transaction using the payment information. The application may transmit the payment information to a server associated with the merchant to process the transaction.