We’ve received quite a few questions recently regarding how CardConnect is different than processors like PayPal (who also owns Braintree) and Stripe, so I thought it would be a timely topic for a blog post. The biggest difference comes down to what merchants are really most concerned about: cost.

Pricing

Both Stripe and PayPal/Braintree charge flat rate pricing, an increasingly popular cost structure for processors. And it’s easy to see why – simplicity is attractive. Flat rate pricing is easy to understand and it saves merchants from the annoyance of sifting through complex credit card processing statements. There’s no risk of missing some fine print and — at least on the surface – it appears to be totally transparent.

 

The flat rate pricing illusion

Flat rate pricing is simple. Credit card processing is not. In fact, flat rate pricing isn’t designed to be competitive at all–the attraction comes from the ease in which merchants can understand the structure. It’s a marketing tactic. With all the intricacies involved in credit card processing, it’s all but impossible for processors to charge a flat rate that is competitive while still remaining profitable as a company. Here’s why.

Whether they’re aware of it or not, every transaction a merchant processes incurs three fees:

1. A fee to the issuing bank, e.g., Chase (interchange)
2. A fee to the card brand, e.g., Mastercard or Visa (assessment)
3. A fee to the credit card processor

While assessments are fixed costs, the interchange rate is not. This rate can vary from as low as 0.05% to over 3%. Processors that charge a flat rate need to account for every possible interchange rate. The good thing about flat rate pricing is that there’s no guesswork and it’s easy for a merchant to figure out how much it’s going to cost them to process their payments. Unfortunately this convenience comes at a cost of spending about 20% more than they have to on processing costs.

Stripe and PayPal/Braintree use a fixed percentage of volume pricing structure of 2.9% + $0.30 per transaction. This is on the higher end in comparison to interchange rates, and for merchants with low ticket transactions that extra $0.30 can be a real burden.

 

“Interchange Plus” pricing optimizes costs

Quite simply, “interchange plus” pricing means the merchant pays the interchange rate plus a fee to their credit card processor. That fee is usually measured in basis points. Each basis point is 1/100th of a percent.

For example, let’s say you’re a retail business working with a processor that charges 70 basis points for a fee of 0.70%. If you ran a card-present transaction of $50 with an exempt Visa check card, the interchange fee would be 0.80% + $0.15 for a combined rate of 1.5%. That gives you an interchange rate of $0.75 + $0.15 for a grand total of $0.90 for the transaction. That same transaction through Stripe or PayPal would cost $1.75!

Funding

Another cost of processing with many flat rate processors is the funding timeline. Since companies like Stripe are technically payment aggregators, it’s not cost-effective for them to maintain the reserve required to fund their clients in a timely manner.

Through PayPal/Braintree, it takes 48 hours to receive your money. With Stripe, it takes a week. That’s seven days between purchase and funding, which can become a huge burden for many merchants, and can complicate accounting long-term.

Another thing–aggregators may process payments under one large merchant account rather than having separate accounts for each of their merchants. In this scenario, the money your customers pay through these services does not belong to you. Since the aggregator is the one with the merchant account, it technically owns the money being processed. The service provider then issues a payment to you for the amount of the transaction.

Other payment processors, like CardConnect, will always have you open and own your merchant account, a process that can be as quick as a few hours. For this reason, any money that your customers pay only ever belongs to you, and you’ll receive your money in as little as one day.

And as for APIs…

Stripe and PayPal/Braintree are lauded for their developer-friendly APIs, and it’s no wonder. They’ve put together a collection of quality SOAP and REST APIs that allow businesses to have control over the customer-facing piece of their payment process. In fact, their APIs are so well-marketed that companies will often overlook the higher prices of processing. What these merchants don’t realize is that they don’t have to make that sort of sacrifice for simple, high-quality developer tools.

Payment processors like CardConnect provide SOAP and REST APIs and developer tools that rival the best in the industry. Plus, if you process with CardConnect, you know your customer’s card data is protected with our patented tokenization process.

In sum

With a little education on pricing, business owners don’t have to settle for a flat-rate structure. Even smaller, low-volume businesses and startups should expect transparency, access to their money when they need it, and a full suite of developer tools. Expect more from your processor – you deserve it.

Interested in taking the CardConnect API for a test drive? Click here.

Remember when I said I’d cover custom .jar files?  Here it is: my follow-up to creating your first Java Concurrent program.

In the previous post, we covered all the steps necessary to create, compile, deploy and run a Java Concurrent Program as made available through the Standard Request Submission form in Oracle applications.  This is a logical way to start, but it may not be the preferred method from a “best practice” point of view.  The more appropriate method might be to compile your solution and archive your class files into a .jar file that represents all components of your solution.

Revising Your Solution

If you selected the option above to package your code under a custom top – within a solution-related .jar file OR if you intend to include any third-party .jar files that are not (and I assume will not be) included in the CLASSPATH of the EBS middle-tier – then you will need to specify the “–classpath” option when creating your Concurrent Program.

The process as outlined in my previous post still stands, however you must specify the following:

If your program relies on third-party .jar files, or if you located your class in a .jar file that is not by default included with the CLASSPATH for the middle-tier application server, see the Special Notes section.

… where the Options field contains the following:

-classpath

/d01/oracle/EBSVIS/apps/apps_st/comn/java/classes:/d01/oracle/EBSVIS/apps/apps_st/appl/au/12.0.0/java/appsborg.zip:/d01/oracle/EBSVIS/apps/apps_st/appl/pps/12.0.0/java/json_simple-1.1.jar

The json_simple-1.1.jar is just an example of including a custom or third-party .jar in the classpath.

This –classpath “overrides” the default CLASSPATH that would be inherited from the middle-tier.  As such, the general specification is:

-classpath <path_to_JAVA_TOP>:<path_to_appsborg.zip>/appsborg.zip:<path_to_your_custom.jar>/custom.jar

This option must always have the following:

1. The path to $JAVA_TOP
2. The appsborg.zip
3. A path and archive for your and/or third-party archives
4. Be specified as the literal path, and may not contain $VARIABLE references
5. Be used when working with archives that are not part of standard CLASSPATH for middle-tier

Conclusion

Although not covered in great detail, remember these key components when compiling your .jar file:

• Echoing Parameters – you could use something similar to the following:

// echo program start and parameters

out.writeln("PPS CardConnect Reconciliation Program - Program start: "
+ PPSUtils.getDateTime() + "n");

int pCount = 0;
String rDate = null, mid = null;

out.writeln("Parameters submitted from CCM:n");

while(parms.hasMoreElements()) {
NameValueType parm = parms.nextParameter();
out.writeln("t(" + ++pCount + ") " + parm.getName() + " = ""
+ parm.getValue() + """);

   if(parm.getName().equalsIgnoreCase("p_date")) rDate = parm.getValue();
if(parm.getName().equalsIgnoreCase("p_mid" )) mid   = parm.getValue();
}

 

• Signaling Completion Status – Use the ctx.getReqCompletion().setCompletion() method as appropriate.  Valid values for completion status are ERROR, NORMAL, PAUSE and WARNING
• Log File and Out File Writes – The log method accepts a second parameter, which is an indication of the type of log entry, although I could not find supporting documentation.  Valid values are int 1..6.

Feel free to leave me any questions in the Comments below.  Good luck!

Writing your first Java Concurrent Program can be intimidating.  You could probably accomplish the same result using a combination of UNIX shell scripting, SQL and PL/SQL, right?  But when an opportunity arose recently for me to embed REST API calls that returned JSON objects, the answer was to do this within a Java environment.

I have, at times, been fatigued by the complexity of the Oracle code.  In fairness, metalink note [ID 827563.1] – yes, I said metalink – does provide a good explanation of the structure and requirements, but I will boil those down even further here.

First, a little background.  Oracle provides an interface with a method called runProgram(CpContext), which is where you need to embed your code.  This method is called from a main thread after program start and initialization.  The CpContext passed as a parameter to this method – and hence to your code – provides access to many of the variables needed to complete your solution, like .log and .out files and a JDBC connection to the database where this program will be run.

To be able to run your program, you need to define a Concurrent Executable and Concurrent Program and provide some indication of where your code resides.  Assuming you already know how to define a Program and Executable, I will cover the registration process for the path to your program.

So, here it is – my 4-step outline of how to approach writing a Java Concurrent Program:

1. Introduce some simple changes to the template provided below
2. Compile and deploy your code to the server where your EBS resides
3. Define the Executable and Program
4. Start having fun!

Template Program

The metalink note adds several comments that clutter the high-level view.  Below is my representation of the program, but note that my package statement is only significant from the perspective that the package and class name will be required during the Executable and Program definition.  Here is the code:

package dak.jcp.test;

import oracle.apps.fnd.common.Context;

import oracle.apps.fnd.common.VersionInfo;

import oracle.apps.fnd.cp.request.CpContext;

import oracle.apps.fnd.cp.request.*;

import oracle.apps.fnd.util.*;

import java.sql.*;

   public class TestJCP implements JavaConcurrentProgram {

      OutFile out;

      LogFile log;

      public void runProgram(CpContext ctx) {

         Connection conn = null;

         try {

            out = ctx.getOutFile();

            log = ctx.getLogFile();

            ParameterList parms = ctx.getParameterList();

            conn = ctx.getJDBCConnection();

            int userId = ctx.getReqDetails().getUserInfo().getUserId();

         // insert your code here

            log.write("Hello World", 0);

            out.write("Hello World");

            ctx.getReqCompletion().setCompletion(ReqCompletion.NORMAL, "Completed.");

         } catch (Exception e) {

            out.writeln("Exception during PPS Reconciliation...n" + e.getMessage());

            ctx.getReqCompletion().setCompletion(ReqCompletion.ERROR, "Completed.");

         } finally {

            try { conn.rollback(); } catch (SQLException e) {}

         }

      }

   }

Compile your program with the following command:

javac –d $JAVA_TOP TestJCP.java

This will effectively put your compiled program in the CLASSPATH for the EBS middle-tier Java Runtime.

If, however, you are inclined to locate your code in a custom location – perhaps within a .jar file or in a directory structure outside the Oracle application tier (a practice I fully endorse!) – then perform the steps that I will cover in a second blog post.  For now, let’s just keep it simple.

Debug your program as needed. To run your program, you have two options:

1) Use the following syntax to run your code directly from UNIX:

java -Ddbcfile=<dbc filename with full path>

   [ -Drequest.logfile=<logfile name> ]

   [ -Drequest.requestid=<request id> ]

   [ -Drequest.outfile=<output file name> ]

   [ -Drequest.userid=<user id> ]

   [ -Drequest.respapplid=<resp appl id> ]

   [ -Drequest.respid=<resp id> ]

   [ -Drequest.secgrpid=<sec grp id> ]

   [ -Drequest.enabletrace=<Y/N> ]

   oracle.apps.fnd.cp.request.Run   <program/class name>   [<parameters>]

2) Define the Executable and Program, point it to your new code and try running via Standard Request Submission form.  Oddly, I find this second option easier.

Defining Your Executable and Program

Now, login to EBS as developer or System Administrator and define an Executable similar to the following:

The Execution File Name is the name of your class, and the Execution File Path is the package reference from your program.

Next, define a Concurrent Program like this:

Lastly, be sure to add the Concurrent Program to the appropriate Request Group so you can run it.

Now, run it!

The Execution

Although not terribly exciting, your output should take the following form:

Output File:

Log File:

If you have any questions, post them in the comments below.  I’d love to hear your experiences with Java Concurrent Program.