WebSite X5Help Center

 
Garry Faegenburg
Garry Faegenburg
User

Payment Processing Suggestion  en

Autor: Garry Faegenburg
Visitado 2365, Seguidores 2, Compartilhado 0  

It is my sincere hope that the developers and folks who control the budget for your product will listen to my suggestions for product improvement in regatrds to Payment Processing options for Website X5 Pro.

Let me state first that I am trying to word my suggestion from several different perspectives.  I say this because most importantly I truly LOVE this product.  I was a Systems Programmer for 34 years on IBM Midrange and Mainframe computers and got my start in 1981 just a couple of years before the advent of the Personal Computer.  I believe my roots in hardware/software give me an in-depth viewpoint of what makes a product good and what makes a product not so good (see, I am trying to be diplomatic sealed ).

I was never a website developer, but when my knowledge base expanded during the last decade of my career, my interest in the Internet and how the infrastructure of it all works, combined with my desire to learn how to make my own personal website, started a quest on my part to finally put all my years of experience together to learn how to do it all.

I spent a LOT of time and wasted effort trying to find the web development platform that would meet my needs.  I went from Microsoft Front Page, To Adobe Dreamweaver, To Dot-Net-Nuke, to WordPress and a couple of others, and ALL left me wondering why no one has come up with a better solution.  And to be honest, the most powerful lesson I learned from all of this was that Microsoft Front Page, the original web development tool created in the early 1990's was so easy to use right out of the box, that simplicity was the key to success in development tools.

Unfortunately, simplicity can sometimes lead to a product that is lacking in functionality because the complexities of what it takes to make great functionality are many times not exposed in the efforts to keep the product simple and easy to use.

OK, now we get to the meat and potatoes here.  Those last two paragraphs I wrote, are the key to the point I would like to make to the Website X5 team.

Your product from an ease of use standpoint is the BEST I have ever seen.  And the functionality you provide in the product, especially from a cost standpoint is top notch!  I have spent ten times the price of X5 Pro over the years on products and add-ins and training, etc. that were light years away from what you guys have brought to the table.  An amazing feat for sure!

My reasons for purchasing your product came about from a personal standpoint.  I wanted a website development tool to make my own personal statement, a non-business site.  And I was blown away with the results I was able to achieve.  You can check out my site at:  http://www.thefaegenburgs.com

It was shortly after I got that project to it's current state, that I began a journey to start my own small business, and I wanted to manage everything myself.  And so I now have my own company, I developed the website, I run it myself on my own equipment here in my home, and the only recurring fees I have to pay relate to Licensing, Security, and Payment Processing and Invoicing.

And now you will forgive me for having to get into the reason for this suggestion post.

My business, being of a sensitive product line (Firearms), has brought to light the difficulties in securing Payment Processing for this type of business.  I can't use PayPal, AmazonPay, ApplePay or any of the vast majority of free services out there.  If I could, there would be no need for this suggestion post.

Businesses such as mine, need the capabilites of Authorize.Net (the biggest player out there) or other similar gateway solutions.

I don't pretend to know how easy or difficult it is to provide this capability to your product, but I do know it costs money for sure.

But I think, if you guys (pardon me for saying guys all the time, I don't mean to exclude the ladies as I am sure you have many on the team! laughing) want to make this product a huge e-commerce hit, you need to expand in the area of Payment Processing.

When I discovered how easy it was to set up the shopping cart and how the products couldbe so easily displayed on a page, I was REALLY wow'ed!!  

But when I finally figured out what I was up against for Payment options because of the nature of my products, I quickly became dismayed.

However, I credit the foresight of the development team to provide the Custom Code feature on the Payment Option setup.  Clearly you were thinking ahead here.

But I think, now that the Payment Processing standards appear to have settled into a somehwat organized structure (most gateways work in a similar fashion), I think you could extend your capabilities to a much wider offering of built in Payment Processing options.

I know the world is a bit different across the pond.  I think much of your community resides in European communities.  The PayPal option works well for a large base of businesses over here in the USA, but we have a lot of business types such as mine, that simply can't use the inexpensive or freebie Payment options.  We need access to gateway's like Authorize.Net.

So I am asking you to please consider this in future versions of your product.

Here is one thing I can tell you about that I know most of the Payment Processors over here provide with their product.  They offer a tool to provide Web Forms for generating Payment Processing web pages.

I have been able to use this to create the HTML code necessay to plug into the Custom Code field you provide on creating a Payment Processing option in your shopping cart.

However what it lacks, is not being able to pass the information from the Shopping cart pages, over to the final Payment Processing pages necessary to complete a transaction within a website.

But I know it can be done.  The question is, what would be the most expediant and cost effective way for you to provide that to your customers who buy Website X5.

I see two ways to approach this.  One is through better documentation, because I know as a programmer, your product already has the code base to do this last little step (pass the info from the shopping cart over to the Payment Processing page).  It must be there because you already do that for the built in Payment Options you currently have.

So from a documentation standpoint, provide us with the variable names and HTML code examples of how we can modify our Custom Code, to get the few values we need to present on the Payment Processing page?

The other way, is to just add more Payment Processing Types to the list.  However, I think with the large number of providers out there, each with unique interfaces, it would cause you to have to duplicate a lot of static code in the product.  It makes it prettier and easier for your customer to choose a Payment Processing type to present to their customers on the website no doubt, but I think the real way to do it is through a simple API and some good documentation.

The API would simply provide a common frontend for us to take the values we need from Shopping Cart summary, add pass them through to our Custom Code for the Payment Processing page.

Then all we would have to do, is plug this standardized API section of HTML code into the Custom Code field on the Payment Processing setup.

I know I am oversimplifying the process, but I know you can do that without a ton of effort.

In about 6 months I have to make the decision as to whether or not I want to pay for continued maintenance of the product.  The product as it stands, provides me about 90 percent of the capabilities I need for both personal website goals and business website goals.

But that last 10 percent is what would make keep paying maintenance if I thought I would continue to get improvements that would get me to 100 percent.

I urge you to make a further investment to make what already is a GREAT product, into a best of breed solution.

Keep up the fine work, and thanks very much for your consideration of this suggestion.

Regards, Garry Faegenburg

P.S. (You can visit my website at:  https://fsasfirearms.com to see how close your product is to providing that last little bit of functionality to open the doors to what I am asking for in this suggestion.  I need to be able to pass the Total number of items ordered, and the total cost of those items, along with the shipping costs, to the Payment Prcessing page.  With that capability, I would have my 100 percent solution.  Would also be nice to be able to populate my customers Billing and Shipping info on the Payment page as well! sealed)

Publicado em
12 RESPOSTAS
JJ. JUAG
JJ. JUAG
User

Wr liest noch so lange Teste, können Sie in 2 - 3 Sätzen erklären, was Sie möchten ?

JJ.

Ler mais
Publicado em de JJ. JUAG
Garry Faegenburg
Garry Faegenburg
User
Autor

Yes I can explain in 2-3 sentences JJ.  The text is long because I wanted developers to know with the right documentation, I could figure out how to write the necessary code, so I know they can as well.

We NEED more Payment Gateway interfaces for US based businesses.  Documentation on how to do the Custom Code is almost zero.  Please make a GOOD product BETTER.

That do it for you???

Ler mais
Publicado em de Garry Faegenburg
Sinisa B.
Sinisa B.
User

@ Garry

I can feel your "frustration".

A major update of the e-commerce section - not just the adding a new payment gateways - is a must.

I have written 5-6 post regarding this (many other users too) - but no real reaction from the company.

You can read one of my posts below:

https://helpcenter.websitex5.com/pt/post/218189

***


To be perfectly honest, before the holidays Incomedia wrote that they are considering our requests and they are "working on it"... maybe this is true...but, this part should be updated months (years?) ago - so I'm not too enthusiastic about it...


Ler mais
Publicado em de Sinisa B.
Garry Faegenburg
Garry Faegenburg
User
Autor

Sinisa,  thanks for your post.  I went back through the link you provided and read up on what has been going back and forth on this subject.  What seems so ridiculous is, the fact that they have ANY gateway selections at all just goes to show that adding others is quite easy.

I can understand from their point that which ones to include because of the many countries using the product could be a challenge.

And that is why I went to such lengths on the initial post about why it would at least make sense to provide us an interface to collect internal information into variables that we can insert into the Custom Code field.

AL the gateway providers have Web Forms available.  Once you get the HTML for the Form, plugging everything together in the Custom Code field would be fairly easy.

But if they don't give us docuemtation, how the heck are we supposed accomplish anything?

I know one thing, as much as I like the product (it works fine for my personal website as I don't sell anything there), I will not be paying for updates when it comes to renewal time unless this topic gets addressed.

If necessary, I will move to a new web development tool, maybe WordPress and just relearn everything all over again.

Too bad they seem unwilling to take this to the next level.

Thanks again for sharing.  Wish there was some way to get them to address this!

Ler mais
Publicado em de Garry Faegenburg
JJ. JUAG
JJ. JUAG
User

Thanks for the short form, the topic is much more complex, since there are many 1000, if not more, different payment systems all over the world.It also happens that these are also continuously changed.Years ago we integrated payment systems like Postfinance for Switzerland with a lot of effort, after a few months everything was changed again by the payment institution.

A globally uniform data transfer from shops to payment institutions would be desirable, similar to the IBAN for bank payments in Europe.

JJ.

Ler mais
Publicado em de JJ. JUAG
Garry Faegenburg
Garry Faegenburg
User
Autor

JJ, I understand the issue with the huge number of processors.  But what about my idea of having some of the internal data items that are carried in the Shopping Cart process, available to plug into the HTML Custom Code.

That way, we could generate our Web Forms (which most of the Payment Processors provide), take the HTML code and plug it into the Custom Code field, and then just make the couple of modifications needed for the Payment screen.

If we had Number of Items, Total Cost, Shipping Cost, that would do the job.

I mean the Shopping cart automatically sends the emal to customer and merchant.  I just need to be able to carry the cost and number of items forward to the payment screen.

The Web Form had all the logic to calculate the Credit Card processing Fee, and the Tax.

A simple API to pull the values you want from the internals to plug into the HTML Code fields would be pretty easy to do.

Ler mais
Publicado em de Garry Faegenburg
Sinisa B.
Sinisa B.
User

@ Garry

Yeah, I hear you!

I had a software company 15 yrs ago - and in the case I would receive so many inputs from my customers telling me the very same thing - I will react immediately.

Since there are users who do not want to code (or do not know how to)  - I believe that your solution should be accompanied by adding i.e. 2checkout, Stripe... plus some other popular payment gateway(s).

This way WS X5 would have enough different payment solutions for the majority of international users.

Yes, this takes time to implement - BUT it would make a market leader out of the WS X5 - and would attract many more users... But it seems that Incomedai is not into increasing their customer base the way that it should be increased and not by just selling new web-templates for an "unfinished" product...

Incomedia, sorry for being so "harsh" - but I can not finish my web shop for 6 months now for the reasons that any other company would fix in a heartbeat.

I hope you could "redeem" yourself IF the next update would contain serious updates and fixes of the e-commerce.

Ler mais
Publicado em de Sinisa B.
Michael M.
Michael M.
User

1+

Ler mais
Publicado em de Michael M.
Incomedia
Stefano G.
Incomedia

Good afternoon Garry

First of all, I'd like to thank you for all the enthusiasm you are displaying for the product. We really do appreciate that.

Your Idea topic is published correctly so that it can be kept under careful consideration for the future. I just wanted to add something to this matter here which perhaps could prove useful in the meantime.

In the Custom Code section, there are some ready-to-be-collected variables that you can use actually. I will post them here:

[ORDER_NO]
[PRICE]
[NAME]
[LASTNAME]
[ADDRESS1]
[ADDRESS2]
[CITY]
[STATEREGION]
[COUNTRY]
[ZIPPOSTALCODE]
[EMAIL]
[PHONE]
[ADVERTS]
[NOTE]
[COMPANY]

By inserting these in that space, the respective values will be printed into the code. Of course, it still depends on how your code is structured whether these can help or not, but it is worth saying that they are there if you plan on using them

I hope I was helpful

Stefano

Ler mais
Publicado em de Stefano G.
Garry Faegenburg
Garry Faegenburg
User
Autor

Stefano,

That is actually VERY useful information sir!  Can I ask if there is also a variable for the Shipping cost?  I was starting to look into some of the .php files to see if I could make sense out of any of it, but unfortuneatly I am a neophyte HTML and PHP person.  I was an RPG programmer on IBM Midrange systems, but knowing programming helps when you are trying to make sense out of any coding language.

I noticed in one of the .php files I was looking at, there is an array that is carrying all of the items for an order that gets displayed on the Shopping Cart Checkout screen.

I am also assuming that there has to be a variable that knows how many elements are in the array.

If I had that variable, the variable that carries the shipping cost, I think I might just be able to tinker around and figure out how to get those values into the Web Form HTML code that I plug into the Custom Code field for the Payment Processing option.

I am almost tasting victory here Stefano!  Are those couple of other variables available as well.

I think you might just have given me the info to be able to get things wrapped up and I am truly grateful for that information!!!!

Let me know if you have the answer on those other two variables.

Thanks VERY MUCH!!

Ler mais
Publicado em de Garry Faegenburg
Garry Faegenburg
Garry Faegenburg
User
Autor

I also wanted to throw this out there Stefano, for you and also to anyone who reads this post and may be wondering if there is help out there to address this problem.

I had a conversation this afternoon with a very knowledgeable guy out in California who actually writes Gateway Payment Solutions for a living as well as a lot of other neat stuff including web hosting.

His name is Paul Baptist and his company is BigCloudMedia.com

He was very helpful in educating me on various options to potentially solve this issue for Website X5.  Incomedia might want to consider enlisting his expertise in developing a product solution for our beloved Website X5 Pro.  He does know his stuff.

Here is his contact information for anyone interested:

Paul Baptist

Big Cloud Media

(408)364-6171

www.bigcloudmedia.com

***

Ler mais
Publicado em de Garry Faegenburg
Incomedia
Stefano G.
Incomedia

Hello Garry

Unfortunately, those are all the variables that the software currently uses and that you can make use of in your custom code. Every other data needs to be retrieved in a different way, for which I am unfortunately unable to help.

I hope that will prove to be useful to you nonetheless

I thank you for your understanding and remain available for any clarification

Stefano

Ler mais
Publicado em de Stefano G.