The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards a payment abstraction layer that (among other benefits) enables software developers to set up and/or enhance application programs to accept several payment tenders (where “tender” generally refers to any type of value that is being exchanged, including credit card, debit card, check, coupons, loyalty, and so forth) without requiring the application programs to implement the particular details of each payment solution provider. With such a payment abstraction layer and architecture, each payment service provider may provide the functionality needed to properly complete a payment transaction with their service. Integration with each payment provider needs to be done only once, and is performed by the service provider. As a result, the payment abstraction layer architecture eliminates the integration costs, and facilitates straightforward and seamless integration between different application programs and different payment processors.
In one example implementation represented herein, the payment abstraction layer comprises a client-side .NET class library in a Windows®-based operating system environment, which allows application programs (e.g., written by independent software vendors) to abstract the information needed for a particular payment service provider. However, it can be readily appreciated that such an abstraction layer can be implemented in other ways, in other environments, and/or with other operating systems. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used in various ways that provide benefits and advantages in computing and payment processing in general.
Turning to
In general, regardless of the type of payment receiving device, the payment-enabled application program running thereon is able to interface with a payment abstraction layer 112 to communicate suitable payment-related information thereto. In turn, the payment abstraction layer 112 interfaces with an appropriate payment service provider (from among an available payment acquirer/processor set 114) for the type of payment being made. Example payment service providers represented in
The payment abstraction layer 112 standardizes tenders (that is, payment instruments) for the payment-enabled application program 220, regardless of the payment mechanism (the source) and the payment provider (the destination). Moreover, because in the example implementation the payment abstraction layer 112 runs above the operating system 222, any devices capable of running an operating system may act as payment terminals, including conventional personal computers, SmartPhones, Mobile PocketPCs, television set-top boxes and so forth.
As described herein, one way the interfacing may be accomplished is by writing the application program to call defined methods (e.g., a standardized API set) of the payment abstraction layer 112. To this end, in this example the payment-enabled application program 220 interfaces via an IA-PAL interface with an IPOS interface of the payment abstraction layer 112. Note that the payment abstraction layer 112 also includes an interface ID that allows the payment abstraction layer 112 to consume the input from any standard payment instrument, e.g., a magnetic stripe card 224, a smart card 225 and a contact-less card 226 are shown as examples. Alternatively, or in addition to, the payment-enabled application program 220 may accept the input.
As also represented in
In general, the payment objects comprise plug-in code modules or the like, e.g., created by the payment service providers. Via the payment objects, application programs that interface with the payment abstraction layer 112 effectively couple to one or more payment services (PS) provided by a particular payment service provider 214, which in turn couple to the processing platforms 231-234 of the service provider 214 to process payment transaction on their services.
As represented in the example of
As also described above, the payment abstraction layer interfaces and payment service enumeration API 344 allows developers of payment-enabled applications to support any payment service provider, without having to program the details necessary for supporting particular payment service providers. This is facilitated via the payment objects (e.g., three are shown, labeled 346-348), each typically comprising a module created by a payment service provider, which provides the code necessary to properly format a payment message and appropriately route the message. Most of the payment processing work is thus done by the payment service provider's payment object, thereby providing the payment object developer with a high level of customization. This customization may take several forms, e.g., a payment object supporting multiple tender types, a payment object supporting multiple payment platforms from the same service provider, a payment object that uses a new or different type of encryption data flowing from the payment object to the service provider, and so forth.
As generally represented in
The Tender class is a base class that acts as a container for tender data covering most of the tender types that exist today. There are several different payment tender classes derived from this class for the different payment types. As shown in
In general, most of the classes in the hierarchy 450 of generic payment instrument classes (i.e., tender classes) serve as containers to store the data needed to process multiple tenders (e.g., instead of just one) that have similarities in processing requirements. Classes in the tender hierarchy thus comprise generic containers for storing payment instrument data, such as magnetic stripe track data, magnetic ink character recognition data, and so forth, without necessarily knowing the actual payment instrument type. By way of example, a credit card, a debit card and a gift card can each have magnetic stripe track data. In case a card of any type is swiped through a magnetic stripe device, the application does not necessarily need to determine what kind of card it is. Instead, it puts the track data into an instance of PaymentCard and passes it as a parameter to a method of the processing object (e.g., a UniversalProcessingService object, described below with reference to
Note that the payment abstraction layer architecture is extensible to support new tender classes that may be introduced/adopted in the future.
Returning to
Management APIs 354 also may be provided to assist in the management of the payment objects (while not managing the payments themselves). Management may include providing various functionality such as configuration, monitoring and statistics. Configuration allows a payment object to obtain business-specific information, for example, merchant ID, terminal ID and/or to specify which processing platform a merchant is using.
Also shown in
As described above, a payment object comprises a code module that allows applications to connect to one or more payment services provided by a payment service provider. A payment service is a configuration of a payment object for a merchant to connect to a particular service provided by a payment service provider. Each payment service is associated with a payment object installed on the system. To use a payment object, the application needs to instantiate the payment object for the payment service in the context of the payment service and passing the object for the service it wants to use.
When a payment object is installed on a machine that is available to a payment application, the application can enumerate all the available payment services the payment object provides. The application can choose the appropriate payment service that provides the functionality needed by the merchant needs to process payments, then the application can create an instance of that payment object and process payments as needed.
To provide enumeration functionality in one example implementation, the payment service enumeration API 344 (e.g., corresponding to a PaymentExplorer class in the payment abstraction layer 112) provides a way for the payment-enabled application 220 to enumerate the payment services that are available, in order to create an instance of the appropriate payment object. The PaymentExplorer class includes functionality for enumeration of service providers; for example, via PaymentExplorer, the application 220 can enumerate available payment services in a number of ways. These include getting the payment service that matches the required payment service name, getting the default payment service that supports the specified tender type, getting all available payment services, and getting the payment services that conform to a particular criteria specified, e.g., tender type, compatibility and so forth.
Via enumeration, the application can create an instance of the payment object that refers to a particular payment service that the application wants to use. For enumeration in one example implementation, methods include GetDefaultService, which takes tender type and optionally tender subtype as parameters and returns the default service for that type/subtype. The methods returns a PaymentServiceInfo object that has metadata information about the default payment service. A GetServices method enumerates the available payment services for the payment-enabled application, returning a collection of PaymentServiceInfo objects for any payment services that conforms to the particular selection criteria, e.g., supported tender type, and compatibility. The GetService method returns a particular payment service for the specified name as a PaymentServiceInfo object that has metadata information about that particular payment service. Service names are unique, and if a service with such a name does not exist, GetService returns null.
With respect to instantiation, in one example implementation a CreateInstance method creates a payment object instance of the appropriate payment object installed that provides the functionality needed to process the payment service that the application wishes to use. The application 220 calls the CreateInstance method to create an instance of the payment object that provides the functionality needed for the payment service with which it wants to interact. The application passes the particular PaymentServiceInfo object as a parameter to CreateInstance method, and CreateInstance returns a PaymentService object that needs to be casted to the appropriate processing interface class, such as UniversalProcessingService (described below).
An example summary of how instantiation occurs follows, in which the application calls PaymentExplorer.CreateInstance(PaymentServiceInfo) to create an instance of the payment object associated with the service with which the application wants to interact. CreateInstance returns a PaymentService object that needs to be casted to the appropriate payment processor interface class. Most commonly, it will be casted to UniversalProcessingService interface.
More particularly, one or more universal payment processing interface classes may be provided, e.g., in the form of a UniversalProcessingService class 560 (
In general, the UniversalProcessingService 560 provides a generic processing interface capable of processing multiple payment instrument types, which masks tender-specific processing requirements from the application. Depending on a given application's requirements, the application may need synchronous or asynchronous processing of payments. In one example implementation, the UniversalProcessingService interface 560 provides functionality to handle both synchronous and asynchronous processing of payments.
For example, when an application can process one payment transaction at a time and is able to wait for that payment transaction to finish before starting a new payment transaction, then the application uses the synchronous interface of the UniversalProcessingService. Some of the synchronous operations provided by UniversalProcessingService interface to process payments include Authorize, Charge, Credit, Refund, Settle, Void, and so forth.
When an application needs to process multiple payment transactions at a time and cannot wait for a particular payment transaction to finish before starting new payment transactions, then the application uses the asynchronous methods of the UniversalProcessingService interface 560. Some of the asynchronous operations provided by the UniversalProcessingService interface for such processing include BeginAuthorize, BeginCharge, BeginCredit, BeginRefund, BeginSettle, and so forth. For each of the asynchronous operations, the begin operation needs to be ended using an appropriate ‘End’ operation, e.g., EndAuthorize, EndCharge, EndCredit, EndRefund, EndSettle, and so forth.
As generally represented in
If a new payment type gets adopted by/introduced into the market that needs a different payment processing interface than that provided by the UniversalProcessingService class, the payment abstraction layer 112 can be easily extended to add another payment processing class to handle this new payment type. In this case, the PaymentService object that was returned by CreateInstance would be casted to this new class type, rather than UniversalProcessingService. Note that the UniversalProcessingService class itself can be extended later (e.g., add new properties/methods/events) to support more functionality.
By way of an example in
Note however that while the payment abstraction layer APIs are extensible, adding new interface classes is undesirable because payment applications would have to be re-written to support the new processing class. New classes should only be added if found that the new tender requiring support cannot be handled by the functionality already provided by the UniversalProcessingService interface.
Returning to
As described herein, some of the operations provided by the UniversalProcessingService interface class include:
The above operations correspond to methods of the UniversalProcessingService class. The tender processing methods such as Authorize, Charge, and the like take the parameters including PaymentData, a container object that details the payment amount; Tender, a container object that details the payment tender and BasketData, an optional container object that provides the details about each item in the consumer's basket such as Name, Price, Quantity, and TaxRate.
The following section details the classes in one example Payment namespace.
Members
Members
Methods
Values
Members
AuthenticationResult Enum gets the result of payer authentication. For example, a customer can be asked to sign the receipt (when using a credit card) or enter a Pin (when using a debit card). The AuthenticationResult would reflect the result of authenticating the customer's signature or Pin in those cases.
Values
Members
1) basketData
2) discountAmount
3) item
Methods
1) item
Members
1) description
2) productCode
3) unitPrice
4) quantity
5) unitOfMeasure
6) discount
7) taxRate
8) taxAmount
Methods
Values
Members
Currency Struct—this class contains information about the currency. It is used as a parameter in the PaymentData class and InquireAccountData method to determine the currency to be used.
Members
1) code
2) name
NOTE: only a few of the currency code that are in the Enum are mentioned here since the list in the actual Enum is comprehensive to contain all the available currency codes. These codes were derived from: http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html
Values
Members
1) totalAmount
2) cashbackAmount
3) taxAmount
4) taxData
5) customerCode
6) currency
7) recurring
8) invoice
Methods
This class may be an abstract base class for PAL exceptions such as: PaymentObjectException and PaymentLibraryException.
1) message
2) exception
3) errorCode
4) serializationInfo
5) streamingContext
Exceptions thrown:
Additional error handling is done in GetDefaultService and GetService methods. If critical errors are found, then exceptions are thrown. This is detailed in the appropriate method sections.
Members
Methods
1) service
A PaymentService object.
Throws a PaymentLibraryException if no appropriate provider was found that provides the payment service requested.
1) tenderType
2) tenderSubtype
PaymentServiceInfo object for the payment service or null if none was found.
Throws a PaymentLibraryException exception if there is more than one appropriate payment service available and none of them is set as default.
1) serviceName
PaymentServiceInfo object for the payment service or null if none was found.
Throws a PaymentLibraryException exception if there is more than one payment service available with the same name.
1) tenderType
2) tenderSubtype
3) compatibility
1) message
2) exception
The inner exception.
3) serializationInfo
4) streamingContext
Values
1) message
2) exception
3) errorCode
4) serialization Info
5) streamingContext
Methods
Values
PaymentResultData class—an object instance of PaymentResultData is returned by some of the payment operation methods of the UniversalProcessingService class. PaymentResultData has information about the result of a payment processing operation.
Members
Methods
Members
Methods
1) tender
TenderProcessing object with the result of the operation.
None
None
Members
Methods
Members
Values
Values
Members
SettlementTenderFields Enum—shows the tender fields required to do a settlement transaction. SettlementTenderFields is returned in PaymentResultData when an “Authorize” transaction is called.
Values
Members
Members
An (e.g., abstract) base class that is associated with an account number. There are several payment tender classes derived from this class for the particular tender types.
Members
Methods
Classes Derived from Tender class
public PaymentCard(byte[] track1, byte[] track2, TenderAuthenticationData authentication Data)
Clone Method
ParselsoTrackData Method
This may be an abstract base class that inheriting classes (such as Check class) can use to pass Check related data during payments transactions. This class is derived from Tender class.
This class is used to send Check related data during payment transactions (such as: paper checks, electronic checks, etc.). This class is derived from CheckBase class.
Members
Methods
Members
1) authenticationType
2) binaryData
3) image
4) signature
Methods
Note: this Enum supports mixed values of the values below. An example of this is a Merchant who needs to send both biometric and signature data in a transaction.
Values
TenderProcessing Enum—an Enum that shows the whether a specific tender can be processed by a service provider. TenderProcessing is returned when the CanProcess method is called.
Values
TenderSubtype class—this is a static class that defines constants for the most popular tender subtypes. For example, in the case of the tender type: “Credit Card”, subtypes would be one of the following: “Visa”, “MasterCard”, “AmericanExpress”, etc.
TenderSubtype.CreditCard class—this is a static class that defines constants for the most popular credit card subtypes:
Constants
Constants
Values
Members
Methods
Members
Values
UniversalProcessingService class—the interface class between the service provider and application. This interface is used when the application needs to process payments synchronously or asynchronously (so, more asynchronous operations can be initiated before the previous ones finish).
Exceptions thrown:
Most of the methods described below return PaymentResultData object which contains the result of the transaction. The “Result” property shows the actual result of the operation, for example the result might be “Approved” or “Decline”, etc.
In some cases though, the operations fail to complete and return a proper result due to a failure (that can be a communication failure, a system failure, etc.). In such cases, the operations will throw an exception. An example of this would be if while an Authorize operation is being committed, the communication with the service provider fails, an exception is thrown in this case.
Members
Methods
1) tender
2) amount
3) referenceId
4) basket
5) offlineApprovalCode
PaymentResultData object with the result of the operation.
1) tender
2) amount
3) referenceId
4) basket
PaymentResultData object with the result of the operation.
1) tender
2) amount
3) referenceId
4) basket
5) authorizationData
PaymentResultData object with the result of the operation.
1) tender
2) amount
3) referenceId
4) basket
5) authorizationData
PaymentResultData object with the result of the operation.
1) amount
2) tender
3) authorizationData
PaymentResultData object with the result of the operation.
None
None
1) tender
PaymentResultData object with the result of the operation.
1) tender
2) currency
PaymentResultData object with the result of the operation.
None
Here is an example of the steps how an application would use this method: When the application is ready to settle the transactions authorized previously (that were added to a batch), the application calls StartBatchSettlement. Then individual Settle calls are done on each transaction in that batch. When the application is done calling Settle for the transactions it wants in the batch, it can now submit the settle requests to the back-end service provider by calling CommitBatchSettlement. Or, instead of calling CommitBatchSettlement, the application can choose to cancel the batch settlement by calling CancelBatchSettlement.
1) batchId
None
Here is an example of the steps how an application would use this method: When the application is ready to settle the transactions authorized previously (that were added to a batch), the application calls StartBatchSettlement. Then individual Settle calls are done on each transaction in that batch. When the application is done calling Settle for the transactions it wants in the batch, it can now submit the settle requests to the back-end service provider by calling CommitBatchSettlement. Or, instead of calling CommitBatchSettlement, the application can choose to cancel the batch settlement by calling CancelBatchSettlement.
PaymentResultData object with the result of the operation.
Here is an example of the steps how an application would use this method: When the application is ready to settle the transactions authorized previously (that were added to a batch), the application calls StartBatchSettlement. Then individual Settle calls are done on each transaction in that batch. When the application is done calling Settle for the transactions it wants in the batch, it can now submit the settle requests to the back-end service provider by calling CommitBatchSettlement. Or, instead of calling CommitBatchSettlement, the application can choose to cancel the batch settlement by calling CancelBatchSettlement.
None
1) tender
2) amount
3) referenceId
4) basket
5) callback
6) state
System.IAsyncResult object which represents the status of an asynchronous operation
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) tender
2) amount
3) referenceId
4) basket
5) callback
6) state
System.IAsyncResult object which represents the status of an asynchronous operation
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) tender
2) amount
3) referenceId
4) basket
5) callback
6) state
System.IAsyncResult object which represents the status of an asynchronous operation
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
Starts an asynchronous refund transaction to refund the given amount back to the payee based on a previous charge or settle transaction.
1) tender
2) amount
3) referenceId
4) authorizationData
5) callback
6) state
System.IAsyncResult object which represents the status of an asynchronous operation
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) tender
2) amount
3) referenceId
4) authorizationData
5) callback
6) state
System.IAsyncResult object which represents the status of an asynchronous operation
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) authorizationData
2) callback
3) state
4) referenceId
5) amount
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) callback
2) state
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) callback
2) state
3) tender
4) authorizationData
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) callback
2) state
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) callback
2) state
1) asyncResult
System.IAsyncResult object which represents the status of an asynchronous operation
1) from
2) to
3) expiration
4) callback
5) state
System.IAsyncResult object which represents the status of an asynchronous operation
System.IAsyncResult object which represents the status of an asynchronous operation
PaymentAssemblyAttribute Class
1) paymentObjectProvider
1) name
2) description
3) compatibility
SupportedTenderTypeAttribute class—shows the supported tender types/subtypes attributes.
RestaurantPaymentData class—this class is derived from the PaymentData class.
LodgingBasketItem class—this class is derived from the BasketItem class. This class provides additional basket information specific to a Lodging business.
LodgingExtraCharge Enum—shows the extra charges that the customer incurred during the lodging stay.
LodgingPaymentData class—This class is derived from the PaymentData class.
1) amount
2) folio
3) checkInDate
4) checkOutDate
5) stayDuration
6) roomRate
7) extraCharges
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.