How the Greenlist Works

Think of Greenlist as “Positive Pay for e-Commerce™.” Just as positive pay services validate checks and ensure that only authorized checks are paid, electronic payments protected by the Greenlist are verified and validated before they are paid.

The Greenlist registry adds another authentication factor that proves that the payer and his device that generated the payment instructions are verified to be authorized. Furthermore, this new factor proves that the account address that receives the e-payment is certifiably owned by the party intended to be paid.

Independent verification of the payer’s authorization to pay a correct transaction destination is a “double-check” that does not require any extra user steps or any release of confidential information. In fact, the Greenlist lookup function serves both parties in an X2X transaction to locate and identify each other without either of them needing to release any personal information. With Greenlist, the true account identifiers of both transaction parties never has to leave the banks.

Here’s how it works.

Customer Registration

When a person or business registers to use Greenlist, that consumer or business owner provides an easy to remember unique identifier (through a bank portal), often an electronic mail address, mobile phone number or nickname, to serve as their Greenlist ID. These unique ID’s are assigned accurate, actionable public payment addresses then they are stored in a global network of directories managed by Payment Pathways on behalf of its accredited registrars (banks).

These new e-payment addresses are linked to the consumer’s primary bank account and/or debit card which the bank or financial institution already has stored on file. The registrar bank also issues the customer a special debit-blocked Personal Account Number (PAN) that conforms to INCITS/ISO/IEC 7812-1-2000 and 7812-2-2000.

The consumer is taught to use this PAN in every card-not-present payment transaction. The bank acts as the custodian for personal and account information in the X2X transaction just as it would for any other financial transaction for that consumer. As a result, the bank retains its trusted position at the center of electronic payments in the consumer’s financial life.

Protection for Card-Not-Present Transactions

The Greenlist is highly flexible in the kinds of payment transactions it can protect and, as a result, in the number of ways banks can use it to generate income. The following example of a card-not-present transaction between a consumer and an online merchant shows how Greenlist works to protect online payments.

This example features the Greenlist registry, along with servers for matching and communications, to provide both the Positive Pay for eCommerce service and authentication factors to mitigate the risks of fraud. The transaction runs on existing payment processing rails with only a few additions to the consumer’s device and the merchant’s systems.

First, the customer is assumed to be registered with Greenlist through his or her bank, having received a Greenlist ID (GLID) and Personal Account Number (PAN). Also, the Positive Pay for eCommerce mobile application has been installed on the consumer’s computer or mobile device at the time of enrollment. During that installation, the cloud-based Greenlist application, in concert with the Greenlist mobile app, certifies that the consumer’s GLID and Greenlist PAN have been activated.

For their part, merchants, motivated by their desire to reduce fraud losses from systemic chargebacks, have added a few lines of code (Greenlist libraries) in the checkout part of their shopping carts to support Greenlist interactions and to provide Positive Pay for eCommerce.

For Greenlist registered consumers and merchants, here’s how a card-not-present transactions with Positive ePayment works:

  1. The Consumer (Payer) uses his or her computer or mobile device to initiate making a payment via the online Merchant’s web portal. The consumer’s Greenlist PAN (essentially, a Greenlisted Debit Card Number) will be used as the chosen payment method.
  2. Code in the Merchant’s system queries the Greenlist (or special bin lookup) to find out whether the customer’s card number is a valid Greenlisted PAN. If the response is positive, it returns a simple positive acknowledgement including the consumer’s phone number. Then the Merchant’s system:
    • Queries the consumer’s Greenlist app for its Greenlist ID by sending a Greenlist Query Message in a prescribed format that includes the Merchant’s GLID via SMS. The mobile device generates an automatic response used to validate the mobile device as the source of the Greenlisted PAN given to the merchant.
    • Sends transaction initiation information, including the Greenlisted PAN, to the Matching Server (MS). There, the information is date-time stamped, hashed, and stored.
    • Processes the payment request to the Consumer’s bank through its usual payment processing network.

    Note that if there is no valid response from the Greenlist mobile app, the Merchant will continue processing the payment request as usual. However, the Merchant would not ship product without a confirming message from the consumer’s bank; lack of a response means that the probability is high that the payment will not be explicitly authorized by the true card holder.

  4. The matching server (MS) verifies the PAN received from the Merchant and waits to correlate it with a corresponding transaction verification request from the consumer’s bank. The matching server can be either owned by the bank and kept on the premises or accessed through the cloud, depending on bank preference. Note that the matching server only receives the consumer’s PAN if the Merchant was successful in querying the Greenlist app installed on the consumer’s mobile device (or PC via IM). By previous agreement with the merchant, card issuing bank, and acquiring bank, the Matching Server will have up to 60 minutes to receive and process a matching transaction verification request from the consumer’s bank. If none is received during that time, then the card issuing bank will reverse the payment authorization.
  5. The consumer’s bank processes the payment request from the Merchant’s system. It verifies that the PAN is not in the bad-number bin, and finds the PAN in the Greenlisted bin. Having verified the PAN, the consumer’s bank makes sure that the consumer’s actual bank account has sufficient funds available to cover the purchase. If funds are available, the payment authorization is sent to the merchant in the usual manner.
  6. Because the consumer’s PAN was found by the card issuing bank to be in the Greenlist bin, Positive Pay for eCommerce check is now initiated. The card issuing bank sends the transaction information, including the consumer’s PAN, the Merchant’s PAN, and the payment amount, to the Matching Server.The Matching Server time stamps, hashes, and stores this information upon receipt. Then the Matching Server searches for earlier transaction information that would match the information just received.
  7. If the Matching Server discovers a valid match, i.e., if the debit received from the merchant matches the transaction information provided by the consumer through the Positive Pay for eCommerce application within the 60 minute window, then the bank maintains its ‘Payment Authorized’ message that was previously delivered to the merchant. The transaction is settled through the existing payment network infrastructure to the merchant’s bank, and a credit is posted to the merchant’s account in the usual manner.
  8. If the Matching Server does not discover that a previous transaction had been submitted within the past 60 minutes, the Matching Server will decode the merchant name by doing a reverse lookup of the merchant PAN in the Greenlist registry. Then:
    • The Matching Server passes on the amount and merchant name with the consumer’s contact information to a Callback Server. These values are found with a reverse lookup to the Greenlist registry using the consumer’s PAN.
    • The Callback Server (CS) contacts the consumer’s mobile phone associated with the consumer’s Greenlisted PAN to inform the consumer that the payment was not verified. It asks the consumer to verify or cancel the transaction. The message can be sent as an automatic telephone call, a text message, or an email message, depending on what the user’s preferences obtained during enrollment.
  9. If the Matching Service determines that the transactions do not match, then the consumer’s bank notifies the consumer to obtain his or her authorization through a pre-arranged channel, such as a phone call or text message. If the payer does not authorize the transaction, then the transaction is reversed through the merchant’s bank.

The major benefit of the Greenlist, again, is that no personal or sensitive information (beyond what merchants require for shipment of physical goods or licensing digital goods and services) had to be provided. The card issuing bank enforces that the consumer’s PAN can never be used to generate an automatic debit without a Positive Pay authorization, proving that the consumer’s PAN indeed was input from a smart phone or PC device containing an installed app with a properly enrolled GLID.

If a fraudster uses a stolen Greenlist PAN to pay for a subscription or recurring bill payment service, the consumer is protected by the mobile apps’ logic that would either discover a.) that merchant’s PAN is not in the Greenlist at all and NOT respond affirmatively to the merchant query or b.) the merchant is legitimate but a stolen PAN is paying for someone else’s benefit.

In the second case, the merchant’s query to the mobile app would fail because the merchant’s GLID would not be in the app’s approved list of payee GLIDs for subscriptions and recurring billpayments. In this scenario, the legitimate merchant does not submit the PAN, the match then fails and the consumer would be notified. If the consumer input his Greenlisted PAN into a subscription service from his PC but forgot to add the Merchant’s GLID to his mobile app, it would be automatically added for him when he is called back the first time for that merchant by his bank’s Positive Pay for eCommerce service.

Hackers would never have money sent to a Greenlisted PAN because that would paint a clear trail to their doorstep.

This Positive Pay for eCommerce service is feasible and straightforward for all parties involved because the transaction mechanisms and procedures for high-volume uses like card-not-present transactions are well understood. Capital expenditure required of the bank is minimal.

For additional information, contact Richard O’Brien at 312-346-9400