|
|
|
|
|
|
Payment Services
Managing Purchases and Processing Orders services also contains a Payment Service, which specifies how payment for an order is authorized and settled. Currently the Payment Service allows credit card payments to be made using the CyberCash, Inc. service. However, the JSP templates, input processors, and Pipeline components allow different services to be integrated. This topic describes the Payment Services in detail.
This topic includes the following sections:
JavaServer Pages (JSPs)
A primary goal of Managing Purchases and Processing Orders services' is to allow you to quickly establish a fully-functioning e-commerce site. To this end, the Payment Service provides you with a JavaServer Page (JSP) template that you can use as is, or customize to better meet your needs. This section describes this page in detail.
Note: For a description of the complete set of JSPs used in the WebLogic Commerce Server Web application and a listing of their locations in the directory structure, see the E-Commerce Summary of JSP Templates
documentation.payment.jsp Template
If a customer has already specified payment information in their user profile, the payment.jsp template (shown in Figure 6-1) provides the customer with a list of credit cards (by type and last 4 digits) for selection. Customers wanting to use an existing credit card can simply click its associated Use button to proceed to the next part of the checkout process.
Note: For more information about user profiles, see "Customer Profile Services" in the Guide to Registering Customers and Managing Customer Services.
Customers can also choose to update the information associated with this credit card by clicking the Update This Card button. If your customer wants to use a credit card they have never used on your e-commerce site before, the customer can click the Add Card button to add it to the list (using the paymentnewcc.jsp template). If a customer wants to go back to the previous page, the customer can click the Back button.
Sample Browser View
Figure 6-1 shows an annotated version of the payment.jsp template. The Payment region uses a combination of the WebLogic Server and WebLogic Personalization Server JSP tags to obtain and display the customer's saved credit card(s).
Note: For information on other elements in the payment.jsp template, see Common JSP Template Elements.
Figure 6-1 Annotated payment.jsp Template
Location in the WebLogic Commerce Server Directory Structure You can find the payment.jsp template file at the following location, where WL_COMMERCE_HOME is the directory in which you installed WebLogic Commerce Server: %WL_COMMERCE_HOME%\server\webapps\wlcs\commerce\order\payment.jsp (Windows) Tag Library Imports The payment.jsp template uses existing WebLogic Server and the WebLogic Personalization Server's User Management JSP tags. Therefore, the template includes the following JSP tag libraries: Note: For more information on the WebLogic Server JSP tags or the WebLogic Personalization Server JSP tags, see "JSP Tag Reference" in the Guide to Building Personalized Applications. These files reside in the following directory for the WebLogic Commerce Server Web application: %WL_COMMERCE_HOME%\server\webapps\wlcs\WEB-INF (Windows) Java Package Imports The payment.jsp template uses Java classes in the following packages and therefore includes these import statements: Location in Default Webflow Customers arrive at payment.jsp from the page where they select their shipping address (selectaddress.jsp). If they choose to add a new credit card, they will be directed to the paymentnewcc.jsp template. If the customer chooses to edit one of the cards that appears in the list, the customer will be directed to the paymenteditcc.jsp template. After selecting a credit card for payment, customers move on to the final page in the checkout process, where they can review their order prior to committing it (checkout.jsp). Note: For more information about the default Webflow, see Overview of Managing Purchases and Processing Orders. Included JSP Templates The following JSP templates are included in the payment.jsp template:
$WL_COMMERCE_HOME/server/webapps/wlcs/commerce/order/payment.jsp (UNIX)<%@ taglib uri="weblogic.tld" prefix="wl" %>
<%@ taglib uri="um.tld" prefix="um" %>
$WL_COMMERCE_HOME/server/webapps/wlcs/WEB-INF (UNIX)<%@ page import="java.servlet.*" %>
<%@ page import="java.servlet.http.*" %>
<%@ page import="com.beasys.commerce.webflow.*" %>
<%@ page import="com.beasys.commerce.webflow.tags.*" %>
<%@ page import="com.beasys.commerce.axiom.contact.*" %>
<%@ page import="com.beasys.commerce.ebusiness.customer.*" %>
Events
The payment.jsp template presents a customer with several buttons, each of which is considered an event. These events trigger a particular response in the default Webflow that allows customers to continue. While this response can be to load another JSP, it is usually the case that an input processor or Pipeline is invoked first. Table 6-1 provides information about these events and the business logic they invoke.
Dynamic Data Display
The purpose of the payment.jsp template is to display a list of the customer's previously saved credit cards. This is accomplished on the payment.jsp template using a combination of WebLogic Server and WebLogic Personalization Server JSP tags and accessor methods/attributes.
First, the getProfile JSP tag is used to set the customer profile (context) for which the credit cards should be retrieved, as shown in Listing 6-1.
Listing 6-1 Setting the Customer Context
<um:getProfile
profileKey="<%= request.getRemoteUser() %>
profileType="WLCS_Customer" />
Next, the getProperty JSP tag is used to retrieve a cached copy of the possible credit cards for the customer from the database, as shown in Listing 6-2.
Listing 6-2 Retrieving the CreditCardsMap for the Customer
<um:getProperty propertyName="creditCardsMap" id="creditCardsMapObject" />
You can now iterate through the credit cards contained within the creditCardsMap (using the WebLogic Server JSP tag) and display each credit card in the collection (using a Java scriptlet) as shown in Listing 6-3.
Listing 6-3 Iterating Through and Displaying the Credit Cards
<table>
<wl:repeat
set="<%=(Map)credtCardsMapObject).keySet().iterator()%>"
id="creditCard" type="String" count="100000">
<tr>
<td><%=creditCard%></td>
</tr>
</wl:repeat>
</table>
Note: For more information on the WebLogic Server JSP tags or the WebLogic Personalization Server JSP tags, see "JSP Tag Reference" in the Guide to Building Personalized Applications.
Form Field Specification
The payment.jsp template does not make use of any form fields.
paymentnewcc.jsp Template
The paymentnewcc.jsp template (shown in Figure 6-2) allows customers to enter information about a new credit card, which will be added to their profile. This information includes the credit card type (VISA, MasterCard, and so on), the name on the card, the card number, the card expiration date (month and 4-digit year), and the billing address (including a street address, city, state, zip/postal code, and country). The customer must click the Save button for the new credit card to be added to the customer's list of credit cards.
Sample Browser View
Figure 6-2 shows an annotated version of the paymentnewcc.jsp template. The New Credit Card region provides customers with a series of form fields that allow customers to add a credit card. This region utilizes the form fields defined in the included newcctemplate.jsp template file, which itself includes the states.jsp and countries.jsp template files. The import call in paymentnewcc.jsp is:
<%@ include file="/commerce/includes/newcctemplate.jsp" %>
Figure 6-2 Annotated paymentnewcc.jsp Template
Location in the WebLogic Commerce Server Directory Structure You can find the paymentnewcc.jsp template file at the following location, where WL_COMMERCE_HOME is the directory in which you installed WebLogic Commerce Server: %WL_COMMERCE_HOME%\server\webapps\wlcs\commerce\order\ Tag Library Imports The paymentnewcc.jsp template uses Pipeline and Webflow JSP tags. Therefore, the template includes the following JSP tag libraries: Note: For more information on the Webflow and Pipeline JSP tags, see the Guide to Managing Presentation and Business Logic: Using Webflow and Pipeline. These files reside in the following directory for the WebLogic Commerce Server Web application: %WL_COMMERCE_HOME%\server\webapps\wlcs\WEB-INF (Windows) Java Package Imports The paymentnewcc.jsp template uses Java classes in the following packages and therefore includes these import statements: Location in Default Webflow Customers arrive at the paymentnewcc.jsp template from the page where they are given the option of selecting a credit card from their profile (payment.jsp). When customers are finished with this page, customers are returned to the payment.jsp template so customers can make their selection. Note: For more information about the default Webflow, see Overview of Managing Purchases and Processing Orders. Included JSP Templates The following JSP templates are included in the paymentnewcc.jsp template:
paymentnewcc.jsp (Windows)
$WL_COMMERCE_HOME/server/webapps/wlcs/commerce/order/
paymentnewcc.jsp (UNIX)<%@ taglib uri="webflow.tld" prefix="webflow" %>
<%@ taglib uri="pipeline.tld" prefix="pipeline" %>
$WL_COMMERCE_HOME/server/webapps/wlcs/WEB-INF (UNIX)<%@ page import="javax.servlet.*" %>
<%@ page import="javax.servlet.http.*" %>
<%@ page import="com.beasys.commerce.webflow.*" %>
<%@ page import="com.beasys.commerce.webflow.tags.*" %>
<%@ page import="com.beasys.commerce.foundation.pipeline.*" %>
<%@ page import="com.beasys.commerce.axiom.contact.*" %>
<%@ page import="com.beasys.commerce.ebusiness.customer.*" %>
Events
The paymentnewcc.jsp template presents a customer with a single button, which is considered an event. This event triggers a particular response in the default Webflow that allows customers to continue. While this response can be to load another JSP, it is usually the case that an input processor or Pipeline is invoked first. Table 6-2 provides information about these events and the business logic they invoke.
|
Event |
Webflow Response(s) |
|---|---|
|
button(save) |
UpdatePaymentInfoIP |
Dynamic Data Display
No dynamic data is displayed on the paymentnewcc.jsp template.
Form Field Specification
The purpose of the paymentnewcc.jsp template is to provide form fields that allow the customer to enter new credit card information. It also passes hidden information to the Webflow. The form fields used in the paymentnewcc.jsp template, and a description for each of these form fields, are listed in Table 6-3.
Note: Parameters that are literals in the JSP code are shown in quotes, while non-literals will require scriptlet syntax (such as
<%= HttpRequestConstants.CUSTOMER_CREDIT_CARD_COUNTRY %>) for use in the JSP.
paymenteditcc.jsp Template
The paymenteditcc.jsp template (shown in Figure 6-3) allows your customers to modify information about one of the credit cards shown in the credit card list. Editable information includes the name on the credit card, the expiration date (month and 4-digit year), and the billing address (including street address, city, state, zip/postal code, and country). The customer must click the Save button to save the modifications to their credit card.
Sample Browser View
Figure 6-3 shows an annotated version of the paymenteditcc.jsp template. The Edit Credit Card region provides customers with a series of form fields that allow customers to edit a credit card. This region utilizes the form fields defined in the included editcctemplate.jsp template file, which itself includes the states.jsp and countries.jsp template files. The import call in paymenteditcc.jsp is:
<%@ include file="/commerce/includes/editcctemplate.jsp" %>
Note: For information on other elements in the paymenteditcc.jsp template, see Common JSP Template Elements.
Figure 6-3 Annotated paymenteditcc.jsp Template
Location in the WebLogic Commerce Server Directory Structure You can find the paymenteditcc.jsp template file at the following location, where WL_COMMERCE_HOME is the directory in which you installed WebLogic Commerce Server: %WL_COMMERCE_HOME%\server\webapps\wlcs\commerce\order\ Tag Library Imports The paymenteditcc.jsp template uses the existing WebLogic Personalization Server's User Management JSP tags, and the Pipeline and Webflow JSP tags. Therefore, the template includes the following JSP tag libraries: Note: For more information on the Webflow and Pipeline JSP tags, see the Guide to Managing Presentation and Business Logic: Using Webflow and Pipeline
paymenteditcc.jsp (Windows)
$WL_COMMERCE_HOME/server/webapps/wlcs/commerce/order/
paymenteditcc.jsp (UNIX)<%@ taglib uri="webflow.tld" prefix="webflow" %>
<%@ taglib uri="pipeline.tld" prefix="pipeline" %>
<%@ taglib uri="um.tld" prefix="um" %>
These files reside in the following directory for the WebLogic Commerce Server Web application:
%WL_COMMERCE_HOME%\server\webapps\wlcs\WEB-INF (Windows)
$WL_COMMERCE_HOME/server/webapps/wlcs/WEB-INF (UNIX)
Java Package Imports
The paymenteditcc.jsp template uses Java classes in the following packages and therefore includes these import statements:
<%@ page import="javax.servlet.*" %>
<%@ page import="javax.servlet.http.*" %>
<%@ page import="com.beasys.commerce.webflow.*" %>
<%@ page import="com.beasys.commerce.webflow.tags.*" %>
<%@ page import="com.beasys.commerce.foundation.pipeline.*" %>
<%@ page import="com.beasys.commerce.axiom.contact.*" %>
<%@ page import="com.beasys.commerce.ebusiness.customer.*" %>
Location in Default Webflow
Customers arrive at paymenteditcc.jsp template from the page where they are given the option of selecting a credit card from their profile (payment.jsp). When customers are finished with this page, they are returned to the payment.jsp template so they can make their selection.
Note: For more information about the default Webflow, see Overview of Managing Purchases and Processing Orders.
Included JSP Templates
The following JSP templates are included in the paymenteditcc.jsp template:
Events
The paymenteditcc.jsp template presents a customer with a single button, which is considered an event. This event triggers a particular response in the default Webflow that allows customers to continue. While this response can be to load another JSP, it is usually the case that an input processor or Pipeline is invoked first. Table 6-4 provides information about these events and the business logic they invoke.
|
Event |
Webflow Response(s) |
|---|---|
|
button(save) |
UpdatePaymentInfoIP |
Dynamic Data Display
One purpose of the paymenteditcc.jsp template is to prepare the credit card information a customer had previously entered, so the editcctemplate.jsp template can display this information in the payment information form fields. This is accomplished on the paymenteditcc.jsp template using a combination the WebLogic Personalization Server's User Management JSP tags and accessor methods/attributes.
First, the getProfile JSP tag is used to set the customer profile (context) for which the customer information should be retrieved, as shown in Listing 6-4.
Listing 6-4 Setting the Customer Context
<um:getProfile profileKey="<%=request.getRemoteUser()%>"
profileType="WLCS_Customer" />
Note: For more information on the WebLogic Personalization Server's User Management JSP tags, see "JSP Tag Reference" in the Guide to Building Personalized Applications.
Next, the getProperty JSP tag is used to obtain the customer's list of credit cards (and related billing information), which is then initialized with data from the customer object, as shown in Listing 6-5.
Listing 6-5 Obtaining the Customer's Credit Cards and Billing Information
<um:getProperty propertyName="creditCardsMap"
id="creditCardsMapObject" />
<%
Map creditCardsMap = (Map) creditCardsMapObject;
String creditCardKey =
request.getParameter(HttpRequestConstants.CREDITCARD_KEY);
CreditCard defaultCreditCard = null;
defaultCreditCard = (CreditCard) creditCardsMap.get(creditCardKey);
Address billingAddress = (Address) defaultCreditCard.getBillingAddress();
%>
The data stored within the defaultCreditCard and billingAddress objects can now be accessed by calling accessor methods/attributes within Java scriptlets. Table 6-5 provides more detailed information about the methods/attributes for the default credit card, while Table 6-6 provides more information about the accessor methods/attributes on billingAddress.
Form Field Specification
Another purpose of the paymenteditcc.jsp template is to provide the form fields for the customer's modifications and to pass hidden information to the Webflow. The form fields used in the paymenteditcc.jsp, and a description for each of these form fields, are listed in Table 6-7.
Note: Parameters that are literals in the JSP code are shown in quotes, while non-literals will require scriptlet syntax (such as
<%= HttpRequestConstants.CUSTOMER_CREDIT_CARD_COUNTRY %>) for use in the JSP.
Input Processors
This section provides a brief description of each input processor associated with the Payment Services JSP template(s).
PaymentAuthorizationIP
UpdatePaymentInfoIP
Pipeline Components
This section provides a brief description of each Pipeline component associated with the Payment Services JSP templates(s).
Note: Some Pipeline components extend other, base Pipeline components. For more information on the base classes, see the Javadoc.
PaymentAuthorizationHostPC
PaymentAuthorizationTerminalPC
Integration with CyberCash
Part of the functionality provided by the Payment Services is their ability to interact with CyberCash, a service which allows you to accept credit cards from customers over the Internet. However, to run CyberCash with Payment Services, you will need to perform a number of configuration activities so that CyberCash, your financial institution (credit card provider), and the Payment Services can work together as shown in Figure 6-4.
Figure 6-4 CyberCash Interactions Diagram
Note: For more information about CyberCash, Inc. and their payment solutions, see http://www.cybercash.com. Configuration Activities for Using CyberCash The following is a list of the configuration activities you must perform in order to use CyberCash with Payment Services:
Note: For more information about the possible payment models, see Payment Models.
Note: Be sure to carefully read the instructions in the weblogiccommerce.properties file under the Payment Services heading prior to making any changes.
Listing 6-6 Setting the CyberCashConfigFile Property
###############################################
# Properties required for the payment component
###############################################
#
# This property defers payment authorization to the administration tools.
# If set to true, all payment service authorization calls are disabled
# and payment transactions are persisted in a RETRY state. Payments must
# then be reauthorized through the payment administration tool.
#
commerce.payment.defer.authorization=true
#
# CyberCash configuration files contain CyberCash-specific data, such as a
# merchant-id and merchant hash secret. The specific properties in the
# configuration files depend upon the payment model assigned to a merchant by
# his/her financial institution. The two files declared below are example files # and are provided for demonstration purposes ONLY. MERCHANGS MUST ACQUIRE A
# CYBERCASH CONFIGURATION FILE FROM CYBERCASH. These will be furnished by
# CyberCash as part of the merchant agreement. Once a merchang has a CyberCash
# configuration file, the property below must be replaced with the location of
# the configuration file.
#
# Example: CyberCashConfigFile=c:/merchang/config/file/location/merchant_conf
# This file may be used for testing terminal based payment models.
CyberCashConfigFile=@BEA_WEBLOGIC_COMMERCE_SERVER_HOME@/eval/common/CyberCash/
conf/merchant_conf-terminal
# This file may be used for testing host based payment models.
CyberCashConfigFile=@BEA_WEBLOGIC_COMMERCE_SERVER_HOME@/eval/common/CyberCash/
conf/merchant_conf-host
Note: Single front slashes (or double back slashes) are required in this location specification.
Note: For instructions on how to use the Payment Management Administration Tool, see Using the Order and Payment Management Pages.
Listing 6-7 Setting the PaymentModel Property
#
# Properties below represent the different payment models provided # by CyberCash.
#
# Terminal based models
PaymentModel=AUTO_MARK_AUTO_SETTLE
# PaymentModel=AUTO_MARK_AUTO_SETTLE_AVS
# PaymentModel=AUTO_MARK_MANUAL_SETTLE
# PaymentModel=AUTO_MARK_MANUAL_SETTLE_AVS
# PaymentModel=MANUAL_MARK_AUTO_SETTLE
# PaymentModel=MANUAL_MARK_AUTO_SETTLE_AVS
# PaymentModel=MANUAL_MARK_MANUAL_SETTLE
# PaymentModel=MANUAL_MARK_MANUAL_SETTLE_AVS
# Host based models
#PaymentModel=HOST_AUTHCAPTURE
#PaymentModel=HOST_AUTHCAPTURE_AVS
#PaymentModel=HOST_AUTH_POSTAUTH
#PaymentModel=HOST_AUTH_POSTAUTH_AVS
Note: Detailed documentation for CyberCash, Inc. products can be found online at http://www.cybercash.com/cashregister/docs/.
Payment Models
There are two types of payment models: terminal-based and host-based. The difference between these payment models is where the transaction batch is stored. For a host-based model, the transaction batch is stored on the host network rather than on the local system at the merchant's site. Settlement typically occurs sometime at the end of the day, and the merchant is not required to do anything to initiate the settlement process.
For a terminal-based model, the transaction batch is stored as data files on the local system at the merchant's site. Merchants must initiate the settlement process at the end of each day in order for the funds to be transfered to the merchant's bank account.
Table 6-8 describes each of the terminal-based payment models that may be assigned by your financial institution. Table 6-9 describes each of the host-based payment models that may be assigned.
Note: Each of the terminal-based payment models may be suffixed by _AVS. This suffix indicates that merchants are also required to send an address. The WebLogic Commerce Server product always sends this address for verification purposes.
Note: Each of the host-based payment models may be suffixed by _AVS. This suffix indicates that merchants are also required to send an address. The WebLogic Commerce Server product always sends this address for verification purposes.
How Do I Switch Between the Two Payment Models?
If you decide to use the terminal-based payment model, your Web application must use the PaymentAuthorizationTerminalPC Pipeline component. If you decide to use the host-based payment model, your Web application must use the PaymentAuthorizationHostPC Pipeline component instead.
To change the Pipeline component to reflect the payment model, follow these steps:
Note: For more information about the properties associated with the PaymentAuthorizationTerminalPC and PaymentAuthorizationHostPC Pipeline components, see Pipeline Components.
What if I Don't Want to Use CyberCash for Credit Card Processing?
The WebLogic Commerce Server product provides you with a CyberCash-based implementation of a Payment Service. However, you may want to use a service provider other than CyberCash. Use of a different provider requires that you implement a payment authorization Pipeline component that is specific to the provider of your choice.
Note: It is expected that a Java/EJB programmer (or someone with similar technical knowledge and abilities) will develop new Pipeline components.
To implement a new Pipeline component for a Payment Service provider other than CyberCash, complete the following steps:
Listing 6-8 Creating a New Pipeline Component
/ java imports
import java.rmi.RemoteException;
import java.sql.Date;
import java.sql.Connection;
// javax imports
import javax.ejb.*;
// com.beasys imports
import com.beasys.commerce.ebusiness.payment.*;
import com.beasys.commerce.ebusiness.order.*;
import com.beasys.commerce.ebusiness.security.*;
import com.beasys.commerce.axiom.contact.*;
import com.beasys.commerce.axiom.units.*;
import com.beasys.commerce.axiom.util.helper.*;
import com.beasys.commerce.webflow.*;
import com.beasys.commerce.foundation.*;
import com.beasys.commerce.foundation.exception.*;
import com.beasys.commerce.foundation.pipeline.*;
import com.beasys.commerce.util.*;
/**
* This <code>PipelineComponent</code> authorizes a credit card
* for a purchase of a given amount using a payment service other
* than CyberCash. This class is a concrete extension of the
* <code>CommercePipelineComponent</code> abstract base class.
*
* PipelineSession input attributes:
* PipelineSessionConstants.PAYMENT_CREDIT_CARD
* PipelineSessionConstants.PAYMENT_AUTHORIZATION_AMOUNT
* PipelineSessionConstants.ORDER_HANDLE
*/
public class MyPaymentAuthorizationPC extends CommercePipelineComponent
{
Listing 6-9 Implementing the process() Method
/**
* Authorize a credit card for a purchase amount.
*
* @param pipelineSession The current PipelineSession
* @throws PipelineFatalException on fatal error
* @throws PipelineNonFatalException on non-fatal error
* @throws RemoteException on remote error
*/
public PipelineSession process(PipelineSession pipelineSession)
throws PipelineFatalException, PipelineNonFatalException, RemoteException {
//
// Get the order, credit card, and authorization amount from
// the PipelineSession.
//
CreditCard card = (CreditCard)pipelineSession.
getAttribute(PipelineSessionConstants.PAYMENT_CREDIT_CARD);
Price amount = (Price)pipelineSession.getAttribute
(PipelineSessionConstants.PAYMENT_AUTHORIZATION_AMOUNT);
Handle orderHandle = (Handle)pipelineSession.getAttribute
(PipelineSessionConstants.ORDER_HANDLE, PipelineConstants.REQUEST_SCOPE);
Order order = (Order)(orderHandle.getEJBObject());
//Create a Transaction ID
//This can be done with any persistent number generator.
//Every transaction ID must be unique.
//Look at
//http://edocs.beasys.com/wlcs/docs32/javadoc/wlps/com/beasys/commerce/util/Sequencer.html
//for information on the Sequencer interface.
com.beasys.commerce.util.Sequencer mySequencer =
com.beasys.commerce.util.SequencerFactory.createSequencer
("PaymentTransactionIDSequence");
mySequencer.setCacheSize(10); //optional
Connection myConnection = getConnection();
long myTransactionID = 0;
try {
myTransactionID = mySequencer.getNext(myConnection);
} catch(java.sql.SQLException sqlException) {
//Add the appropriate exception handling logic.
}
//
// Decrypt the credit card using the Decryptor service.
//
String creditCardNumber = null;
try {
DecryptorHome home = (DecryptorHome)JNDIHelper.getHome(
"com.beasys.commerce.ebusiness.security.Decryptor");
Decryptor decryptor = home.create();
creditCardNumber = decryptor.decrypt(card.getNumber());
} catch (Exception e) {
// Add the appropriate exception handling logic.
// This will depend on your payment service requirements.
}
//
// Invoke the credit card service authorization method using
// the order, credit card, and authorization amount.
//
// Throw an appropriate exception for authorization error
// condition(s).
//
Logger.getInstance().info("In MyPaymentAuthorizationPC:
calling payment service.");
< Insert credit card service authorization code here >
//
// Immediately nullify the decrypted number.
//
creditCardNumber = null;
//
// If the authorization was successful, create a
// PaymentTransaction entity EJB for the transaction.
// Use the transaction ID returned by the credit card
// service as the primary key.
PaymentTransaction paymentTransaction = null;
try {
PaymentTransactionHome home = (PaymentTransactionHome)JNDIHelper.
getHome("com.beasys.commerce.ebusiness.payment.PaymentTransaction");
PaymentTransactionPk pk =
new PaymentTransactionPk(Long.toString(myTransactionID));
paymentTransaction = home.create(pk);
} catch (Exception e){
// Add the appropriate exception handling logic.
// This will depend on your payment service requirements.
}
//
// Set the PaymentTransaction date, credit card, and amount.
//
paymentTransaction.setTransactionDate(new Date(System.
currentTimeMillis()));
paymentTransaction.setCreditCard(card);
paymentTransaction.setTransactionAmount(amount);
//
// Add a TransactionEntry to the PaymentTransaction and
// mark the PaymentTransaction with the appropriate status.
// In this example, we assume that the payment transaction
// was successfully authorized.
//
TransactionEntry entry = TransactionEntryHome.create();
entry.setIdentifier(Long.toString(myTransactionID));
entry.setEntryDate(new Date(System.currentTimeMillis()));
entry.setTransactionAmount(amount);
try {
paymentTransaction.authorize();
} catch (IllegalWorkflowTransitionException e){
// Add the appropriate exception handling logic.
// This will depend on your payment service requirements.
}
paymentTransaction.addTransactionEntry(entry);
//
// Add a reference to the PaymentTransaction to the order.
//
order.setPaymentTransaction(paymentTransaction);
return pipelineSession;
}
}
As shown in Listing 6-9, the credit card, authorization amount, and order is first extracted from the supplied PipelineSession. Next, the Decryptor security service is used to decrypt the encrypted credit card number. After obtaining all the information necessary to authorize a payment, you must next call your Payment Service provider authorization routine using any of the collected data necessary. Finally, after completing the authorization, a payment transaction is recorded using the PaymentTransaction entity EJB. The PaymentTransaction entity EJB records the date, amount, credit card, and status (in this case, authorized) associated with the payment. It also keeps an audit trail of payment transaction modifications via a collection of TransactionEntry objects. Each TransactionEntry object stores a date, identifier, and amount.
AuthorizePaymentPC.className=com.beasys.commerce.ebusiness.
payment.pipeline.PaymentAuthorizationTerminalPC
Then, modify the AuthorizePaymentPC Pipeline component definition to use your new Pipeline component as follows:
AuthorizePaymentPC.className=MyPaymentAuthorizationPC
You should now be able to authorize payments using the new Payment Service PipelineComponent.
Note: If you replace the existing Payment Authorization Pipeline component, you must administer payments using tools supplied by your Payment Service provider and NOT the administrative Payment Management pages. The administrative Payment Management pages should only be used for CyberCash-based payment administration. For more information about the administrative Payment Management pages, see Using the Order and Payment Management Pages.
Credit Card Security Service
All credit card information your customers provide is considered sensitive and is encrypted for security purposes. This information is decrypted only when absolutely necessary during specific payment processing activities (authorization). For example, on the order confirmation JSP template (confirmorder.jsp), only the last 4 digits of a customer's credit card are displayed.
Notes: For more information about credit card security, see "Credit Card Security Service" in the Security Guide.
For information about other BEA security features, see the Security Guide.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|