we find there is a great demand for Custom Payment Processing solutions that integrates with Oracle Payments (or iPayment as it used to be called when it was part of the earlier releases).
iBizSoft has developed custom solutions for various backend processing systems such as Moneris, Cybersource, Authorize.net, Paypal and many others. Our development primarily focusses on using the API from these payment processing systems and integrating it with iPayment. Easier as it sounds, we have put in hours of development and testing time to come with a seamless solution. Since Oracle Payments are certified only with handful of backend payment processors such as Citibank, PaymentTech, FDC etc., we find there are lots of customers who have their own existing applications that use payment processing system where they get better rates and service due to long term relationships.
iBizSoft solutions cater to such needs of our customers, who would like to implement Oracle Payments without compromising on their dependency to a back end payment system.
Email us at support@ibizsoftinc.com to know more about these solutions.
Sunday, April 26, 2009
Friday, April 24, 2009
Configuring Bins in iStore
You can change the look and feel of the catalog and shopping cart pages by modifying their bin layouts. The seeded pages are divided into bins. Several bins display the content of seeded JSPs. The catalog and shopping cart pages also have bins without seeded source files. You can associate these bins with custom source files to customize the pages’ appearance.
Each bin is listed as a separate logical template in the Oracle iStore template manager.
You can change the bin placement or content in the following ways:
_ Change the profile options that are related to the catalog bins.
For example
You can use the following profile options to enable or disable the section page bins:
_ IBE: Use Global Bin
_ IBE: Use Section Bin
_ IBE: Use Section Path
_ IBE: Use Welcome Bin
_ Associate JSPs with the seeded logical bin templates.
To customize templates for your store, perform the following tasks after planning your web page designs:
_ Gain an understanding of the recommended and/or mandatory page flows through your specialty stores.
_ Create template source files (JSPs) for pages or for blocks within pages. If you are implementing multiple languages, create source files in each of the languages which you plan to support. Or, copy the seededJSPs (save with a new name) and apply your modifications; then, map the new JSP to the page flow through Template Manager.
_ Choose Oracle iStore template names.
_ Register templates in the Store Administration UI.
_ Assign template source files to templates.
Each bin is listed as a separate logical template in the Oracle iStore template manager.
You can change the bin placement or content in the following ways:
_ Change the profile options that are related to the catalog bins.
For example
You can use the following profile options to enable or disable the section page bins:
_ IBE: Use Global Bin
_ IBE: Use Section Bin
_ IBE: Use Section Path
_ IBE: Use Welcome Bin
_ Associate JSPs with the seeded logical bin templates.
To customize templates for your store, perform the following tasks after planning your web page designs:
_ Gain an understanding of the recommended and/or mandatory page flows through your specialty stores.
_ Create template source files (JSPs) for pages or for blocks within pages. If you are implementing multiple languages, create source files in each of the languages which you plan to support. Or, copy the seededJSPs (save with a new name) and apply your modifications; then, map the new JSP to the page flow through Template Manager.
_ Choose Oracle iStore template names.
_ Register templates in the Store Administration UI.
_ Assign template source files to templates.
Setting up Custom Qualifiers for iStore
Advanced Pricing in Oracle Ebusiness Suite has provided the functionality to allow us to set up custom qualifiers based on the attribute values in an active cart. Cart header information resides in aso_quote_headers_all and the line information resides in aso_quote_lines_all table.
Based on any of the 15 attribute values in these tables, one can manipulate the price that shows up in a cart. For eg. if the price is driven by a value derived from a hard-copy catalog (one of our customer had this requirement), we provided a text box for the user to enter the catalog code value and click on ‘Update Cart’, this would display a new price based on the attribute mapping setup for this catalog code. This setup is done via Oracle Pricing Manager responsiblity using Attribute Management functionality, as discussed below. Note : We have used Minisite Site Id as our qualifier in this example.
Based on any of the 15 attribute values in these tables, one can manipulate the price that shows up in a cart. For eg. if the price is driven by a value derived from a hard-copy catalog (one of our customer had this requirement), we provided a text box for the user to enter the catalog code value and click on ‘Update Cart’, this would display a new price based on the attribute mapping setup for this catalog code. This setup is done via Oracle Pricing Manager responsiblity using Attribute Management functionality, as discussed below. Note : We have used Minisite Site Id as our qualifier in this example.
Custom iPayment Servlet for Moneris Payment Processor
Developing a custom iPayment servlet for various backend payment processors is a challenge by itself. Reason, no one has an idea on how to get this done or implemented. There is no good documentation to follow to make this a straighforward approach.
Our approach was to first test the APIs that Moneris has provided and make sure they work effectively. Once that was done, we had to make sure that the custom servlet has all the necessary variables that iPayment is expecting. And this is the piece that is not well documented in the implementation guide for Oracle Payments. We will not be discuss the solution in detail, as this involves the code itself.
Email us at support@ibizsoftinc.com to know more about this custom solution.
Our approach was to first test the APIs that Moneris has provided and make sure they work effectively. Once that was done, we had to make sure that the custom servlet has all the necessary variables that iPayment is expecting. And this is the piece that is not well documented in the implementation guide for Oracle Payments. We will not be discuss the solution in detail, as this involves the code itself.
Email us at support@ibizsoftinc.com to know more about this custom solution.
iPayment Introduction
Oracle iPayment is an electronic payment processing solution designed for application developers, system integrators, and enterprises that need to interact with payment processors for their new or existing Internet or client/server e-commerce applications to process Credit Cards or Purchase Cards. It lets you build integrations with financial institutions and payment processors for payment and receipt processing. Oracle iPayment offers easy installation, administration, and extension capabilities. The risk management functionality of Oracle iPayment can quantify and identify fraudulent online transactions for both business-to-business and business-to-consumer models.One needs to install and configure the ECApp servlet before the integration of iPayment can work with the Ebusiness Suite products such as Order Management, Account Receivables and iStore. The ECApp servlet provides an interface to the iPayment engine to process payment related operations such as authorization, capture, and return. The ECApp servlet is primarily used for the PL/SQL APIs provided by iPayment.
One of the advantages of implementing Oracle iPayment are the Risk factors it covers. Risk Factors such as AVS (Address Verification System) Code check, time of purchase, payment amount and various others can be setup for each payee (merchant). Multiple payees (merchant account) can be setup based on various Receivable Accounts it needs to be credited to and this is handled via the iPayment Administrator in conjuction with a Receivable Manager. Its very much possible both these functionalities are handled by person in an organization and it would be advisable to do so. However, in almost all the projects that I was involved in, Receivables Managers were a little wary about the iPayment UI, due to its look and feel and various additional setups that are required. With a little bit of training, this fear, of handling iPayment UI, can be overcome.Oracle iPayment provides APIs for authorization, settlement, and querying transaction status. You do not have to use all these APIs. You can choose to have your EC application handle only authorization, thus reducing development costs but requiring the payee to do more work for settlement and reconciliation. One of the issues that seems to be showing up with iPayment Implementation is that the transactions get authorized but does not get remitted (or funds are not captured) into the merchant’s bank. Since there are many different BEP systems and it has its own APIs, servlets etc. it becomes very important to determine the origin of the issue. For all we know, it could be a compatibility issue between a Verisign or any BEP servlet and iPayment. To resolve such issues it is advisable to log a service request with Oracle and determine the compatibility between iPayment and BEP systems. There could also be instances where a customer did not get a full understanding of the iPayment Concepts or did not go through the Impementation guide -for eg., there are customers who have demanded Oracle why Purchase Cards are not supported by iPayment when it is actually one of their Vendors who do not support that method of payment, because their servlet (the java code) does not support it.It is higly advisable to get a very good understanding of iPayment and Receivables concepts before venturing into implementation stage.
One of the advantages of implementing Oracle iPayment are the Risk factors it covers. Risk Factors such as AVS (Address Verification System) Code check, time of purchase, payment amount and various others can be setup for each payee (merchant). Multiple payees (merchant account) can be setup based on various Receivable Accounts it needs to be credited to and this is handled via the iPayment Administrator in conjuction with a Receivable Manager. Its very much possible both these functionalities are handled by person in an organization and it would be advisable to do so. However, in almost all the projects that I was involved in, Receivables Managers were a little wary about the iPayment UI, due to its look and feel and various additional setups that are required. With a little bit of training, this fear, of handling iPayment UI, can be overcome.Oracle iPayment provides APIs for authorization, settlement, and querying transaction status. You do not have to use all these APIs. You can choose to have your EC application handle only authorization, thus reducing development costs but requiring the payee to do more work for settlement and reconciliation. One of the issues that seems to be showing up with iPayment Implementation is that the transactions get authorized but does not get remitted (or funds are not captured) into the merchant’s bank. Since there are many different BEP systems and it has its own APIs, servlets etc. it becomes very important to determine the origin of the issue. For all we know, it could be a compatibility issue between a Verisign or any BEP servlet and iPayment. To resolve such issues it is advisable to log a service request with Oracle and determine the compatibility between iPayment and BEP systems. There could also be instances where a customer did not get a full understanding of the iPayment Concepts or did not go through the Impementation guide -for eg., there are customers who have demanded Oracle why Purchase Cards are not supported by iPayment when it is actually one of their Vendors who do not support that method of payment, because their servlet (the java code) does not support it.It is higly advisable to get a very good understanding of iPayment and Receivables concepts before venturing into implementation stage.
Integrating Moneris API with Oracle iPayment
Moneris APIs for Ecommerce transactions are very easy to use and the support provided by them has been excellent. However, when it comes to integrating these APIs for Authorization or Capture with Oracle iPayment its an ordeal in its own way. Its not Moneris API that poses a challenge its the poor documentation on the part of Oracle iPayment that has become difficult for us to integrate.
Here is what I found so far.
1. Moneris expects the Port 443 to be open and using HTTPS protocol
2. We will need to convert the Moneris JAVA APIs into servlets and they should be coded in such a way that they must be callable from the Oracle iPayment related URLs
3. There are few entries that is required to go into zone.properties and jserv.properties
4. The name-value pairs that Oracle iPayment expects must be implemented in the Servlet (as request.getParameters) so that the iPayment UI can send the information to these variables.
5. If you get the following error java.lang.NoClassDefFoundError: org/apache/oro/text/regex/PatternMatcher then there is another issue. We will need to add the directory structure org/apache/oro/….. to the $IAS_ORACLE_HOME/Apache/Jserv/servlets directory.
6. After all this you may still get an SSL Handshake error, which is related to the port and https protocol issue.
Since it is still in the research phase, we are not in a position to comment on the rest of the setups required.
Here is what I found so far.
1. Moneris expects the Port 443 to be open and using HTTPS protocol
2. We will need to convert the Moneris JAVA APIs into servlets and they should be coded in such a way that they must be callable from the Oracle iPayment related URLs
3. There are few entries that is required to go into zone.properties and jserv.properties
4. The name-value pairs that Oracle iPayment expects must be implemented in the Servlet (as request.getParameters) so that the iPayment UI can send the information to these variables.
5. If you get the following error java.lang.NoClassDefFoundError: org/apache/oro/text/regex/PatternMatcher then there is another issue. We will need to add the directory structure org/apache/oro/….. to the $IAS_ORACLE_HOME/Apache/Jserv/servlets directory.
6. After all this you may still get an SSL Handshake error, which is related to the port and https protocol issue.
Since it is still in the research phase, we are not in a position to comment on the rest of the setups required.
Subscribe to:
Posts (Atom)