US 12,254,463 B1
Biller directory and payments engine architecture
Alan W. Hecht, San Francisco, CA (US); Sotirios Barkas, San Jose, CA (US); Ann M. Kirk, Deerwood, MN (US); Peter Rozovski, Concord, CA (US); Peter L. Shen, Castro Valley, CA (US); and Chate Yap, Orinda, CA (US)
Assigned to Wells Fargo Bank, N.A., San Francisco, CA (US)
Filed by Wells Fargo Bank, N.A., San Francisco, CA (US)
Filed on Aug. 29, 2019, as Appl. No. 16/555,934.
Claims priority of provisional application 62/787,073, filed on Dec. 31, 2018.
Claims priority of provisional application 62/725,235, filed on Aug. 30, 2018.
Int. Cl. G06Q 30/04 (2012.01); G06Q 20/02 (2012.01); G06Q 20/36 (2012.01)
CPC G06Q 20/3674 (2013.01) [G06Q 20/027 (2013.01); G06Q 30/04 (2013.01)] 20 Claims
OG exemplary drawing
 
1. A payer computing system associated with a payer and communicatively coupled to a biller exchange computing system, a payer computing device, a first biller computing system, and a second biller computing system, the payer computing system comprising a processing resource, a memory resource, and computer-executable instructions stored thereon and embodied in a customer-side application programming interface (API), the instructions, when executed by the processing resource, causing the payer computing system to:
receive, from the biller exchange computing system, the customer-side API, wherein the customer-side API is a distributed API that is deployed on the first biller computing system and the second biller computing system such that the distributed API validates a first payer-biller electronic authentication token and a second payer-biller electronic authentication token, the first payer-biller electronic authentication token and the second payer-biller electronic authentication token being one-time tokens configured to provide a one-time integration between their respective billers and the payer, wherein the biller exchange computing system does not locally store the first payer-biller electronic authentication token and the second payer-biller electronic authentication token;
access, by the payer computing device, a first webpage, the first webpage associated with the biller exchange computing system;
in response to a first electronic payment request received from the first biller computing system via the biller exchange computing system, the first electronic payment request comprising a previously generated first payer-biller electronic authentication token that corresponds to first payer authentication information for the first biller computing system:
validate, via the distributed API, the first payer-biller electronic authentication token;
display the first electronic payment request at the payer computing device via the first webpage;
receive, from the payer computing device via the first webpage, an instruction to initiate a payment transaction;
in response to receiving the instruction to initiate the payment transaction, cause the payment transaction to be initiated by generating electronic instructions based on biller registration data indicating whether a first biller associated with the first biller computing system accepts real-time payments or batch payments and by processing the electronic instructions to transfer an amount of funds determined based on the first electronic payment request from a source account associated with the payer to a target account associated with the first biller over a first payment rail if the first biller accepts real-time payments or over a second payment rail if the first biller accepts batch payments; and
receive, from the payer computing device via a user interface of the first webpage, customer preferences regarding payment processing, the customer preferences comprising an initiating payment indicator indicating whether (i) the payer computing device will initiate future payment transactions via the first webpage or (ii) the biller exchange computing system is authorized to initiate the future payment transactions in response to receiving future electronic payment requests;
in response to the first biller having a security policy requiring an additional authentication mechanism in addition to a first authentication mechanism to access the first webpage via the payer computing device, initiate a secondary authentication mechanism comprising:
decoding the first payer-biller electronic authentication token to provide challenge questions;
in response to decoding the first payer-biller electronic authentication token, requesting additional payer authentication information other than the first payer authentication information via the challenge questions; and
in response to receiving and authenticating the additional payer authentication information, permitting access to the biller exchange computing system; and
in response to a second electronic payment request received from the second biller computing system via the biller exchange computing system, wherein the second electronic payment request comprises a previously generated second payer-biller electronic authentication token that corresponds to second payer authentication information for the second biller computing system:
validate, via the distributed API, the second payer-biller electronic authentication token; and
display the second electronic payment request at the payer computing device via the first webpage;
display, via the user interface of the first webpage, a sequence of screens, each screen of the sequence of screens corresponding to the payment transaction or at least one of the future payment transactions:
receive, via the user interface of the first webpage, a transaction interaction with at least one screen of the sequence of screens, the transaction interaction comprises at least one of a plurality of swipe inputs comprising:
a first swipe input in a first direction, the first swipe input indicative of approval of the payment transaction or at least one of the future payment transactions;
a second swipe input in a second direction, the second swipe input indicative of deletion of the payment transaction or at least one of the future payment transactions;
a third swipe input in a third direction, the third swipe input indicative of flagging the payment transaction or at least one of the future payment transactions; and
a fourth swipe input in a fourth direction, the fourth swipe input indicative of revocation or reversal of the payment transaction or at least one of the future payment transactions; and
in response to receiving the transaction interaction, cause, based on the at least one of the plurality of swipe inputs associated with the transaction interaction, the payment transaction or the at least one of the future payment transactions to be at least one of approved, deleted, revoked, reversed, or flagged for further review.