Direct extension coverage system and method

Abstract

Transactions between account-based endpoints are executed in a two-step process that first verifies the recipient's validity and then executes an operational transfer. Unlike payment prequalification, the qualification verification step verifies the validity of the recipient's account while collecting the information required to complete the transaction dataset. This information may include anti-money laundering and know-your-customer information, as well as specific account details required for onboarding. The recipient payment service provider can be assigned a tokenized bank identification number for routing the transfer through existing financial processing networks. Data construction, minimum required information, and format checks can be facilitated by application programming interfaces on both the initiator and recipient sides.

Description

[0001] Cross-reference to related applications

[0002] This application is filed under the Patent Cooperation Treaty and claims priority to U.S. Provisional Application No. 62 / 858,105, filed on June 6, 2019. Background Art

[0003] The background description provided herein is intended to generally present the context of the present disclosure. To the extent described in this background section, the work of the presently named inventors and aspects of this specification that were not otherwise prior art at the time of filing are not admitted, either explicitly or implicitly, to be prior art to the present disclosure.

[0004] While approximately three billion endpoints are served by major card processing networks, this only accounts for around half of the world’s adults with bank accounts. Some countries have lower payment card penetration or have regulatory restrictions that limit the use of payment instruments. Summary of the Invention

[0005] The features and advantages described in this summary and the following detailed description are not intended to be all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the art from the accompanying drawings, the specification, and the claims. Furthermore, other embodiments may omit one or more (or all) of the features and advantages described in this summary.

[0006] In some embodiments, a system allows financial transfers between endpoints outside of the traditional card-based financial system. A set of application programming interfaces (APIs) allows non-card payment instructions to be generated and routed between endpoints over a network previously limited to card payment processing. A single send payment API provides domestic and cross-border payment options for both card-based and non-card-based recipient endpoints. Payment service providers (PSPs) can be assigned a pseudo-bank identification number or token bank identification number (BIN) in order to have a routable destination in the system. The PSP can then use its own information about participating recipients to transfer funds to the recipient's account.

[0007] For new endpoints, minimal information regarding Anti-Money Laundering (AML) and Know Your Customer (KYC) regulations may be required. Additionally, when pre-checking the endpoint is performed, overall processing efficiency can be improved. Therefore, before initiating a financial transaction, an endpoint query can be sent to the receiving PSP to verify account destination information and collect AML and KYC information. This data can be used to populate the many data fields required for new customers and verify endpoint availability for all transfers. After this initial data collection step, the actual transfer can be initiated. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A system supporting extended reach payment according to the present disclosure is shown;

[0009] Figure 2 Is based on the support of this disclosure to return undeliverable funds Figure 1 system;

[0010] Figure 3 is an illustration of a user device supporting an interface for extended coverage payment according to the present disclosure;

[0011] Figure 4 is a schematic representation of various application program interfaces (APIs) of an extended coverage payment system according to the present disclosure; and

[0012] Figure 5 is a flow chart illustrating a method of routing a payment to a non-card based recipient endpoint using a card-based network in accordance with the present disclosure.

[0013] For purposes of illustration only, the figures depict a preferred embodiment. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods shown herein may be used without departing from the principles described herein. DETAILED DESCRIPTION

[0014] A system that allows funds to be distributed through a card-based transaction network uses assigned pseudo-identities as proxies that allow institutions outside the card-based network to send and receive payments to participating bank accounts or third-party payment accounts such as WeChat Pay. Any number of payment service providers / payment service providers (PSPs) can each be assigned a pseudo-bank identification number (BIN) that allows payments made via the card network to be routed to the PSP with additional instructions that allow the PSP to identify the endpoint of the request.

[0015] Steering Figure 1, which shows an extended coverage payment system 100 that supports the transfer of financial transactions to non-card-based endpoints. The system 100 allows domestic and cross-border push-to-account payments, for example, involving fund transfers to individuals or companies, developer payments, payments to vendors, contractor payments / wages, insurance claim payments, sharing economy income, merchant settlement payments, tax refunds, and remittance payments. The system 100 may include a user device 102, a requester / payer 104, and a transaction processor 106. The transaction processor 106 may be a processor associated with a payment network such as VisaNet and / or Visa Direct. In some embodiments, the user device 102 may be a separate unit, but may be an access point, such as a web page or corporate payment system hosted by the requester / payer 104.

[0016] A payment service provider (PSP) 108 may have a relationship with one or more banks 110 that host one or more recipient accounts 112. In some cases, the bank 110 may be an alternative financial institution, such as a digital wallet provider or other payment system. In some embodiments, the PSP 108 may be a financial service provider that supports cross-border payments, such as Earthport. An acquirer 118 may be a participant in the final settlement of the transaction. In some embodiments, the requester / payer 104 and the acquirer 118 may be the same entity. As used herein, an "initiator" is a requester / payer 104 (or acquirer 118 if the same entity) that connects to the application program interface (API) of the transaction processor 106 to initiate a push-to-account payment (see further details below). The transaction processor 106 may use a database 120 that stores lookup information for non-standard endpoints and onboarding data to identify the requested endpoint, such as the recipient account 112, when extended processing is required.

[0017] Onboarding is the process of adding a client / PSP to a payment network. In an exemplary onboarding process, the PSP may be assigned its BIN. One BIN may be supported for each country / currency. A recipient base URL may also be required. This is a URL provided by the PSP to which HTTP messages can be sent. The client may also provide a public domain and IP address that can be used by the transaction processor to obtain an approved list of businesses to which it can send business. The client may be provided with an IP address so that business set up by the firewall is expected based on the IP address. Security information such as a key identifier and one or more shared secret keys may be provided for encryption, decryption, and signing. In some cases, establishing communication between the two parties may involve a common SSL authentication based on a root certificate and intermediate certificates bound to a trusted certificate authority (CA).

[0018] Database 120 can also serve as an onboarding database and can be used to store previously collected information about PSPs and individual recipients, including local and foreign government restrictions. Onboarding may include not only assigning a BIN to a PSP, but also assigning a virtual PAN to the PSP to act as a proxy in existing transactions, allowing routing to the correct PSP. The pseudo-BIN / pseudo-PAN combination allows the reuse of existing rails for carrying transaction payloads between endpoints and for settling transactions.

[0019] In operation, a funds transfer request 1 may be issued to the transaction processor 106 according to the send payment application programming interface (API) or push API front end 114, the request including sender and recipient details and one or more additional fields or pseudo-BIN / pseudo-PAN. Although the following discussion focuses on funds transfers for non-card-based endpoints, the send payment API / push API 114 may be a single, unified API that receives funds transfer requests and facilitates pushing funds to both card-based and non-card-based accounts. The transaction processor 106 may query the database 120 to allow for eligibility verification of the requesting endpoint. In some embodiments, the request may only include a recipient identifier, and the transaction processor 106 may be responsible for identifying the PSP 108 associated with a particular endpoint.

[0020] The transaction processor 106 can access a second push API 116 associated with the PSP to populate the push message to the PSP 108. As described above, the PSP 108 may have already gone through an onboarding process to establish access points and password security for use with transaction messages. In some embodiments, the PSP 108 can check its information about the recipient account 112 in near real time to obtain account status and recipient details to return a response 3 to the transaction processor 106 confirming the request and providing an estimated posting date. The return response from the PSP 108 may ultimately be sent 4 to the requester / payer 104.

[0021] Just as PSPs require onboarding, some transaction endpoints may also require onboarding, a process that may require the initial participants to fill out extensive details regarding the ultimate recipient's details. This may include AML and KYC information for regulatory compliance. Furthermore, even previously approved recipients may have made changes to their accounts, been added to watch lists, or have other factors that may affect their ability to pass on the payment. To address this issue, a pre-query can be made, which allows many of these details to be returned to the initiator, including account verification, legal status, routing information, and some regulatory data. Unlike simple credit-holding transactions, a pre-query returns not only the issuer's approval of the funds but may also include data from the PSP about the intended recipient. This data can then be used for onboarding and subsequent account verification, significantly reducing the rate of rejected transactions.

[0022] More information about the request and response is detailed in Tables 1-3 below. Based on the information in the request, and if no failure information is found about the recipient account 112, the PSP 108 can issue 5 funds. An example code of a request message for a funds transfer including payment and recipient details is shown below.

[0023]

[0024]

[0025] Example code for a response message indicating successful authorization, destination amount, and expected posting date to the recipient's account is shown below.

[0026]

[0027]

[0028] The approved payment may be sent to a settlement service. Settlement may occur after the transaction, following the normal (business as usual) settlement process, where information about the transaction is shared 6 with the acquirer 118 and the PSP 108. Thereafter, funds may be transferred 7 from the acquirer 118 to the transaction processor 106, and subsequently 8 to the PSP 108.

[0029] Figure 2An exemplary process for returning funds to the requester / payer 104 in the event that the PSP 108 is unable to complete the funds transfer is shown. Tables 4-6 below discuss exemplary elements of the Return API 117 and associated message content in greater detail. The PSP 108 can request a return by sending a message 1 to the transaction processor 106 via the Return API 117. The transaction processor 106 can forward a return message 2 to the requester / payer 104, for example, using the original account and transaction data generated during the original request. Messages 3 to the transaction processor 106 and 4 to the PSP 108 can confirm the return transaction. The return message can provide a reason for the return, such as 'Account Cleared,' so that the database 120 for the recipient endpoint can be updated. As previously described, the settlement process can follow business as usual, with messages 5 sent to both parties, including the actual funds transfer 6 to the transaction processor and 7 to the acquirer 118.

[0030] Several interfaces can be used to implement extended coverage funds transfers. The front-end API or send payment API 114 can expose methods for receiving payment instructions for non-card transactions while still using existing messaging and settlement systems. Transactions can be processed between card networks, automated clearing house (ACH) networks, real-time transport protocol (RTP) networks, and digital wallet networks.

[0031] The receive-side Original Credit Transaction (OCT) API that allows funds to be pushed to a card account can be extended to include additional fields that support transfers to non-card accounts via a PSP to provide a Send Payment API. The additional fields can be parsed from OCT fields that are not necessarily applicable to payments.

[0032] Because there may still be delays between trade acceptance and settlement, an API could be developed to allow for the reversal of modified OCT trades supported by the above APIs in the event that a trade fails to settle. Such circumstances could include closure of the recipient’s account or regulatory ban on the account, to name just two reasons.

[0033] Advanced routing logic allows non-card payment instructions to be routed to PSPs based on various criteria including cost, country coverage, and timeliness of delivering payments. This routing can be assisted by assigning pseudo-BINs to PSPs of participating systems. Pseudo-PANs can be assigned to endpoints associated with PSPs in the same way that a cardholder's PAN can be associated with an issuer. For example, non-card payment messages can be routed to the PSP using the PSP's BIN, while the payload can contain more than previous card-based transactions to include client-specific information used by the PSP to complete the payment. Routing logic can make routing decisions based on information such as sender country, recipient country, currency, BAI (transaction code), amount, payment method, and merchant (CAID) (if any). Digital wallet credentials may increase the number of fields on current OCT payment payloads.

[0034] The API hosted by the PSP can allow a representative component to receive a transaction request, wherein the PSP then completes the payment and is responsible for the settlement of the transaction. The API can use, for example, the HTTP Post method to accept JSON requests. In an embodiment, for the original request, the elements of this API can include an exemplary method as follows (see Table 1). The API field can include, for example, bank ID, bank country code, bank name, initiator ID, initiator name, merchant category code, bank address, amount, transaction currency code, local transaction date and time, name when the recipient is an individual, company name when the recipient is a company, and recipient address. In each case, information beyond what is described can exist in the actual implementation scheme.

[0035] Table 1.

[0036]

[0037] The API response may include details provided by the PSP, including several fields repeated from the initial request (see Table 2).

[0038] Table 2.

[0039]

[0040]

[0041] The response code received at push API 114 (or another API) from push API 116 may provide a code indicating the success or failure of the requested transaction, an example of which is shown in Table 3. Other success or failure codes may be included in the response in actual implementations.

[0042] Table 3.

[0043] Code describe 00 Approved and successfully completed 12 Invalid transaction 13 Invalid amount 14 Invalid account number (no such number) 57 The cardholder is not allowed to conduct the transaction 61 Exceeding the approved amount limit 64 The transaction does not meet AML requirements 65 Exceeding the speed limit 91 Transaction timeout 93 Unable to complete transaction - Violation of law 94 Repeated sending. T2 Invalid routing number

[0044] If the transaction is unsuccessful, the PSP 108 can request that the funds be returned to the originator via the Return API 117. The Return API 117 exposes a method that indicates the transaction to be refunded, and the reason if applicable (see Table 4 below).

[0045] Table 4.

[0046]

[0047] The transaction details object returned in the API may include the reason for the return. An exemplary code for providing the reason for the return is shown in Table 5 below.

[0048] Table 5.

[0049] Code describe RE101 Account not found RE102 Unable to locate the bank using the bank information provided RE103 The payee name does not match the account owner name RE104 Amount exceeds the limit RE105 The ID number provided to identify the payee does not match the account owner RE106 Missing sender data RE107 Missing payee data RE201 Return due to regulatory reasons RE202 Account has been restricted RE203 The receiving bank rejects the transfer RE204 Account closed RE205 The payment was not accepted by the recipient bank because it was not permitted under regulations or policies RE206 The recipient bank returns the payment because the payment is a duplicate; RE207 The recipient does not accept the payment RE208 No reason provided RE301 Return payment based on a good faith request from the sending bank.

[0050] The response to the return funds request may include the API methods illustrated in Table 6 below.

[0051] Table 6.

[0052]

[0053] Figure 3 FIG2 is an exemplary embodiment of a user device 102 illustrating a user interface suitable for use with the extended coverage systems and methods. User device 102 may include a touchscreen 150 that supports various data entry fields via a funds transfer application (not shown). A 'reason' field 152 may allow the user to select a reason for sending funds. These reasons may correspond to a predetermined list of reasons, or the entry may be free. In some countries, a fixed list of reasons may be required to allow for AML checks on transactions. An amount field 154 may indicate the amount to be transferred. The currency may also be indicated by an identifier on the amount, such as $, €, £, etc.

[0054] Source field 156 can be used to specify the source of funds to be transferred. As indicated, a default source, such as a bank account, can be set. In other embodiments, an account from a wallet or payment service can be used as the source, just as the destination account may not be associated with the card issuer / acquirer. 'Receiving Account' field 158 can allow selection from a list, but in other embodiments, it can support free-form entry of account aliases or account details. Once the entry data is entered, a 'Send' button 160 can be used to initiate the transaction. The funds transfer application can include local field qualifiers, remote field qualifiers, or both. In other words, the entered data can be checked for consistency and compliance with input format standards, as well as qualitative checks, such as whether the source account has sufficient funds for the specified transfer amount. For example, the lookup module can access the requester / payer 104 to determine the pseudo-BIN of the PSP 108.

[0055] Location optimization can reduce costs and speed up delivery by selecting better transaction and settlement routes using region, country, currency, and PSP information. Both source and destination characteristics are considered when making decisions about routing, prepayment, and settlement options.

[0056] Figure 4 A schematic diagram of various APIs available on the transaction processor 106 or another server or processor of the extended overlay system 100 is shown in FIG. The various APIs support the payment services of the extended overlay system 100 and define the interactions between an initiator or PSP and the transaction processor 106 for initiating and managing push-to-account payments. The Send Payment API (or Push API) 114 includes protocols for performing the functions described above, including receiving requests to transfer funds to card-based and non-card-based recipient endpoints, as well as requests for pushing funds to a recipient endpoint. The Foreign Exchange API 170 includes protocols for using current foreign exchange rates to determine the amount of funds to be transferred to a recipient endpoint in the destination country's currency if the destination account is a foreign account. The Query Payment API 172 includes protocols that allow an initiator to proactively request the status of an existing payment, and the Status Notification API 174 includes fields for communicating provisional status details of an existing payment request to the initiator. Table 7 lists exemplary status indicators for existing payment requests. Example status message codes for providing notification of changes in the status of an existing payment request are also provided below.

[0057]

[0058]

[0059] Table 7.

[0060]

[0061] The Return Notification API 175 includes a protocol that allows the initiator to receive notification of returned or rejected payments and the reason for the return (see Table 5). The Cancel Payment API 176 includes a protocol that allows the initiator to request the cancellation of an existing payment request, provided the payment is still in progress. Responses to a cancellation request include: 1) Successful cancellation (payment returned), 2) Pending cancellation request (not yet confirmed), and 3) Unsuccessful cancellation. Additionally, the Watchlist API 178 includes a protocol for filtering payment senders and recipients based on a global watchlist.

[0062] Steering Figure 5 , which illustrates a method executed by the transaction processor 106 for routing payments to non-card-based recipient endpoints. At blocks 200 and 202, a pseudo-BIN and pseudo-PAN may be distributed to a PSP 108 that supports transferring payments to non-card-based recipient endpoints. At block 204, a send payment API (first push API) 114 may be exposed to receive a request to transfer funds to a selected non-card-based recipient account associated with the PSP 108. Next, at block 206, the request to transfer funds may be pushed to a second push API 116 associated with the PSP 108. At block 208, a response message may be received from the PSP 108, and the response message may include a recipient account dataset containing information about the recipient account and recipient account holder, such as, but not limited to, AML information, Know Your Customer information, the recipient account holder's legal status, and recipient account details. At block 210, the transaction processor 106 may evaluate this information in the recipient account dataset to determine success factors for fulfilling the request to transfer funds to the recipient account. If the success factor is above the threshold determined at block 212, the funds transfer request may be executed (block 214). If the success factor is below the threshold, the funds transfer request may be canceled (block 216).

[0063] A technical effect of the systems and methods of the present disclosure is a single unified send payment API that includes fields that support domestic and cross-border financial transaction transfers to card-based accounts and non-card-based accounts via PSPs, thereby expanding the coverage of the payment system. Multiple APIs are provided to support interactions between entities of the extended coverage system to initiate and manage payments to recipient endpoints. Another technical effect of the systems and methods of the present disclosure is that data is returned via the destination PSP for use by the initiator to complete AML and KYC information, as well as for the onboarding process of the requester / payer. Another technical impact is the ability to pre-qualify endpoints before initiating a funds transfer. Yet another technical effect is the use of card-based payment rails for non-card-based endpoints such as simple bank accounts.

[0064] These technologies benefit both the network, which can expand the number of endpoints available for transactions, and end users, who can potentially double the number of destinations available for paying for goods and services.

[0065] For purposes of illustration only, the drawings depict the preferred embodiment. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods shown herein may be employed without departing from the principles described herein.

[0066] After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for the systems and methods described herein using the principles disclosed herein. Thus, while specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise configurations and components disclosed herein. It will be apparent to those skilled in the art that various modifications, changes, and variations may be made to the arrangement, operation, and details of the systems and methods disclosed herein without departing from the spirit and scope of any of the appended claims.

Claims

1. A method of routing a payment to a non-card based entity using a card-based network, the method comprising: Assigning pseudo-bank identification numbers (pseudo-BINs) to payment service providers that support endpoints without financial card accounts; assigning a pseudo primary account number (pseudo PAN) to the payment service provider; Exposing a send payment application programming interface (API) that receives a request to transfer funds from a sending account of a card-based network to a recipient account of a non-card-based entity, wherein the send payment API includes fields for transmitting: Amount of payment; Sending account; as well as Recipient's account; parsing the request to determine the pseudo-PAN; determining the payment service provider based on the pseudo PAN; generating a forward query to the payment service provider using the pseudo BIN associated with the pseudo PAN; receiving a response to the advance query from the payment service provider, the response including a recipient endpoint data set; evaluating a recipient endpoint data set to determine a success factor for satisfying said request to transfer funds; comparing the success factor to a predetermined threshold; In response to the success factor exceeding a predetermined threshold, preparing a transaction payload including data from the recipient endpoint dataset; and The transfer is performed using the transaction payload to transfer funds from a sending account of the card-based network to a recipient account of the non-card-based entity.

2. The method of claim 1 , further comprising exposing a receive response application program interface (API), wherein the receive response API includes fields for transmitting: Return payments; and Rejected payment.

3. The method of claim 2 , wherein the receiving response comprises a code indicating one selected from the group consisting of: approved and successfully completed; Invalid transactions; Invalid amount; Invalid account number (no such number); Denying the cardholder the right to conduct transactions; Exceeding the approved amount limit; The transaction does not meet the requirements; Exceeding the speed limit; Transaction timeout; Inability to complete transactions – Violation of laws; Repeated sending; and Invalid routing number.

4. The method of claim 2 , wherein the receiving response includes a code indicating a reason for the payment return, the reason for the payment return comprising one selected from the group consisting of: Account not found; The bank could not be located using the bank information provided; The payee name does not match the account owner's name; The amount is higher than the limit; the identification number provided to identify the payee does not match the owner of the account; Missing sender data; Missing payee data; Return for regulatory reasons; The account has been restricted; The receiving bank rejects the transfer; The account has been closed; The payment is not accepted by the recipient bank because the payment is not permitted under regulations or policies; The recipient bank returns the payment because it is a duplicate; The recipient does not accept the payment; No reason was provided; as well as Return payment based on a good faith request from the sending bank. 5 . The method of claim 1 , further comprising exposing a status notification application program interface (API), wherein the status notification API includes fields for conveying intermediate status details.

6. A method according to claim 5, wherein the intermediate status details include an indication that the transfer request has been received and is being processed, an indication that the payment has been sent to the recipient account, an indication that the transfer request has been rejected, an indication that the payment has been returned to the sending account, or an indication that the transfer request is pending additional information.

7. The method of claim 1, wherein the recipient endpoint data set includes onboarding data including identity information and legal status of the recipient account holder.

8. The method of claim 7, wherein the recipient endpoint data set includes anti-money laundering information.

9. The method of claim 7, wherein the recipient endpoint dataset includes know-your-customer information.

10. The method of claim 1, wherein evaluating the recipient endpoint dataset comprises identifying settled account messages in the recipient endpoint dataset.

11. The method of claim 1 , wherein evaluating a recipient endpoint dataset comprises identifying legally held messages in the recipient endpoint dataset.

12. A computer-implemented method for routing a payment to a non-card-based recipient endpoint using a card-based network, comprising: Assigning pseudo-bank identification numbers (pseudo-BINs) to payment service providers that support payments to non-card-based recipient endpoints that do not have financial card accounts; assigning a pseudo primary account number (pseudo PAN) to the payment service provider; exposing a first push application programming interface (API) that receives a request to transfer funds from a sending account of a card-based network to a recipient account, the recipient account being a non-card-based endpoint associated with the payment service provider, wherein the request to transfer funds includes fields for conveying: Amount of payment; Sending account; the recipient account; and The pseudo BIN and the pseudo PAN; pushing the request to transfer funds to a second push application programming interface (API) associated with the payment service provider; receiving a response from the payment service provider, the response including a recipient account data set associated with the recipient account; evaluating the recipient account data set to determine a success factor for satisfying the request to transfer funds to the recipient account; comparing the success factor to a predetermined threshold; as well as The request to transfer funds from a sending account of the card-based network to a recipient account of the non-card-based endpoint is performed in response to the success factor exceeding a predetermined threshold.

13. The computer-implemented method of claim 12, wherein the recipient account data set includes anti-money laundering information.

14. The computer-implemented method of claim 12, further comprising exposing the first push API that receives the response from the payment service provider, wherein the response received from the payment service provider includes a response code indicating one or more of: approved and successfully completed; Invalid transactions; Invalid amount; Invalid account number (no such number); Do not allow the recipient account to trade; Exceeding the approved amount limit; Exceeding the speed limit; Transaction timeout; Inability to complete transactions – Violation of laws; Repeated sending; and Invalid routing number.

15. The computer-implemented method of claim 12, further comprising exposing a return application programming interface (API) that receives a return request message from the payment service provider when the payment service provider is unable to complete the request to transfer funds to the recipient account, the return request message including a request to return funds to the sending account and a reason for returning the funds to the sending account.

16. The computer-implemented method of claim 12, further comprising exposing a watch list application programming interface (API) that screens the sending account and the recipient account against a global watch list.

17. The computer-implemented method of claim 12, further comprising exposing a cancel payment application program interface (API), the cancel payment API receiving a request to cancel the request to transfer funds to the recipient account.

18. A system for routing payments to a non-card based recipient endpoint, comprising: Requester / Payer; Payment service providers that support payments to non-card-based recipient endpoints that do not have a financial card account; as well as A transaction processor configured to execute computer-executable instructions for: Assigning a pseudo-bank identification number (pseudo-BIN) to a payment service provider; assigning a pseudo primary account number (pseudo PAN) to the payment service provider; exposing a first push application programming interface (API) configured to receive a request to transfer funds from the requester / payer from a sending account of a card-based network to a recipient account, the recipient account being a non-card-based endpoint associated with the payment service provider, wherein the request to transfer funds includes fields for conveying: Amount of payment; Sending account; Recipient's account; as well as The pseudo BIN and the pseudo PAN; pushing the request to transfer funds to a second push application programming interface (API) associated with the payment service provider; receiving a response from the payment service provider, the response including a recipient account data set associated with the recipient account; evaluating said recipient account data set to determine a success factor for satisfying said request for a funds transfer; comparing the success factor to a predetermined threshold; as well as The request to transfer funds from a sending account of the card-based network to a recipient account of the non-card-based endpoint is performed in response to the success factor exceeding a predetermined threshold.

19. The system of claim 18, wherein the transaction processor is further configured to execute computer-executable instructions for exposing a return application program interface (API) for receiving a return request message from the payment service provider when the payment service provider is unable to complete the request to transfer funds to the recipient account, the return request message including a request to return funds to the sending account and a reason for returning the funds to the sending account.

20. The system of claim 18, wherein the first push API is a single unified API that receives requests to transfer funds to both card-based and non-card-based recipient endpoints.

Images