Browse Prior Art Database

A method and implementation of a pluggable software wrapper for Payment Servers Disclosure Number: IPCOM000030912D
Original Publication Date: 2004-Sep-01
Included in the Prior Art Database: 2004-Sep-01
Document File: 3 page(s) / 123K

Publishing Venue



A program is disclosed that defines a pluggable middle layer whose purpose is to separate the logic layer from the execution layer about ecommerce financial transactions. This software provides an open architecture and hot-plug deploying to minimize fix/upgrade costs and unavailability time for maintenance.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

A method and implementation of a pluggable software wrapper for Payment Servers


    A merchant -who want to open his business to e-commerce- needs a software to manage the shop catalog and an operational back-end to realize the financial transaction in electronic way.

Generally there are four actors in this execution path:
1. a buyer, a consumer acquiring goods using a Web browser;
2. the merchant software, the software which supports the merchant Internet business using a Payment Server to process and manage Internet payments.This software will generally include Web-based software for browsing catalogs, managing shopping carts and placing orders;
3. the payment software (PS in the follow), used to process orders, translate and forward requests to appropriate payment gateway;
4. a financial back end.

Ideal requisites to manage PS services

    When the native merchant software needs some interaction with the financial system then through a simply embedding process it can use the PS services. This way can have different effects on software maintenance and upgrade (in the code or architecture): a minimal change on the PS can need upgrade, re-test, re-deploy of merchant software and unavailability of the Web site with lose of transactions.

    This pattern doesn't satisfy a set of requisites which can facilitate custom software to have interactions with financial systems.

It should be: R1. Not strong tied with the merchant main software, to have a minimal impact on business process or software changes;

R2. Not strong tied with a well defined PS, to provide wide access at different kind of available PS;

R3. Able to reduce unavailability time in case of maintenance or upgrade;

R4. Easily upgradeable and adaptable with new products or technologies.

A method to support pluggable PS adapters

    The proposed layer accomplishes a meta-PS fu...