E-Payment processing software for Delphi

[alogrep 0]

Hola

Does anybody have experience with E-Payment processing software for Delphi?

Any suggestions for a good good software for Delphi (11)?

How does it work, once the software is integrated into the APP: is it a one time licence or does the developer have to pay for each end-user that uses the app.

I am 100% new to this field.

Thanks

Enrico

[David Schwartz 426]

This has little to do with Delphi, per se, and more to do with using Delphi to access your payment procssor's API. It probably belongs in another part of the site as it has nothing to do with VCL.

 

If you don't have any experience calling REST APIs in Delphi, then play around with some free ones first.

 

Then find a payment processor you like that has a public API and use Delphi to access it. They'll probably have examples of several languages, like js, python, php, etc. Not likely any Delphi example. So what? If it's a REST API, just use Delphi's REST debugger and go from there.

 

TMS Software has the VCL Cloud Pack which implements an API for PayPal.

 

https://www.tmssoftware.com/site/cloudpack.asp

 

They also have their FNC Cloud Pack (a cross-platform library) that supports PayPal and SumUp

 

https://www.tmssoftware.com/site/tmsfnccloudpack.asp

 

Stripe also has a REST API you could call with examples for several languages: Ruby, Python, PHP, Java, Node.js, Go, and .NET, as well as a basic Curl example.

 

https://stripe.com/docs/api

 

There's also a platform called Plaid that offers services to talk with several banking platforms:

 

https://plaid.com/docs/api/

 

(There are actually a bunch of services similar to Plaid you can use.)

 

But all of this is simply payment processing. If you're looking at using Delphi to build the next eBay, Amazon, or Shopify, that's a whole 'nuther can of worms, and I would not recommend Delphi as the implementation platform. That said, I've worked at a number of places that sold various services and did integrated billing -- some that supported healthcare providers like Doctors and Dentists, and others that just did various other specific services.

 

Explain your use-case and you might get some more substantive insights.

 

 

 

Edited June 9, 2023 by David Schwartz

[alogrep 0]

Thanks, David.

My case is simple, no next eBay or Amszon. .

I have a POS for restaurants, and one client has asked me if I could integrate the payment process into the App.

Now they use the terminals supplied by their Bank for register the payment, then manually register that payment  in the App.

I told him I would investigate. 

SORRY. I forgot to add that the client also wants his customer to be able to order and pay online, remotely. I can handle the ordering part, but have no idea about the payment processing online.

Edited June 9, 2023 by alogrep

[tgbs 14]

Ordinary POS are connected with a cable to a "computer" or via Bluetooth. POS terminals have firmware and a protocol by which they connect to the bank and the provider. You need a technique to talk to POS and send the commands according to the corresponding protocol.

[Rollo62 536]

Aside the technical challenges, my first question would be, how much Apple and Google will Charge for such InAppPurchase of a burger?

 

If you run locally on your own infrastructure, thats fine, but an app in the stores has myriad of restrictions.

Or are you talking about Windows even?

 

 

[alogrep 0]

Rollo62. Yes I am talking about Windows.  And there are 2 scenarios: one all inside the restaurant (with the Server connected to the web), the other when a customer posts an order remotely and wants to pay remotely.

 

[chenech 0]

I use a PayTef company terminal, connected to Wi-Fi, from the application I generate a JSON file with the amount, the invoice number, etc., I send it to them through a PayTef API, once the client has paid or cancelled, I receive an acceptance or rejection code, so I can control payments from my application and for remote payments also through PayTef, a link is generated that is sent to the client by email and I can know if they have paid or not or if the payment has expired the shipment.

Paytef | Solución de pago para empresas 

The protocol is very simple, but I don't know if they work outside of Spain

[David Schwartz 426]

What country is your client in? This can be very important.

 

I don't think typical restaurants can afford what it would cost for you or anybody to do this DIY. It's something I _could_ do, but I wouldn't touch it with a 10' pole. Too much liability for my taste.

 

I'd urge you to look around at vendors who sell turn-key POS + Web solutions that can suck in the existing content and have it up and running in a week or so. There are HUNDREDS of them! Many even include a mobile app with online ordering.

 

Also, ask any hardware vendors you're talking with about security requirements, like PCI and some other things; they'll vary by country.

 

Square has a popular POS package that includes a cash drawer if needed, as does Clover.

 

There are some that provide a case for a mobile phone with a card swiper.

 

And there are also the table-top devices that have games for the kids and let you pay your bill when you're done.

 

I would highly recommend NOT doing this yourself. 

[FPiette 383]

4 hours ago, David Schwartz said:

I don't think typical restaurants can afford what it would cost for you or anybody to do this DIY.

He just has a first customer. He will sell it a a price under his costs and will then sell it to other customers.

[David Schwartz 426]

6 hours ago, FPiette said:

He just has a first customer. He will sell it a a price under his costs and will then sell it to other customers.

I don't get that intepretation from the OP. He did say, I am 100% new to this field although it's unclear to me what "field" he is talking about. It could be several, including: programming; Delphi; restaurants; ecommerce; online payment processing; and others.

 

I have worked in a half-dozen companies that did online payment processing, and I learned several things: (1) online payments are very security-centric; (2) they take a long time to solve and get certified; (3) they can take several dedicated resources, so are very expensive; (4) there are considerable legal and financial liabilities involved in a DIY approach; (5) he wants both POS and web-based, which are two completely different cans of worms; (6) a one-man shop will be more likely to go bankrupt before finishing.  

 

The last place I was at, monitoring compliance for PCI and something else kept three people busy full-time, and it required a computer be set up in an isolated room with multiple security barriers and no direct connection to the internet or even WiFi access. I remarked to my boss one day how I thought it was rather excessive and he almost blew a gasket. I do not pretend to understand it very deeply, only that the companies I've worked for who did this stuff took it extremely seriously.

 

My take-away was simple: let someone else invest the time and money into building and maintaining a secure solution that meets all of the legal compilance stuff, and just buy or lease it from them.

Edited June 12, 2023 by David Schwartz

[alogrep 0]

Hola David.

The field is the subject and the content of the post: E-Payment processing software for Delphi.

Perhaps is not the right wording, but what I was trying to get suggestions/hints about is how to allow a POS application to process a payment made with credit/debit cards. I found something, for example Stripe and a Delphi wrapper (https://github.com/gmurt/ksStripe).

It appears that one could add that payment processing library to an application. 

I do not intend to develop myself a Stripe-like software, but use it or something similar in a Delphi 11 app.

I have developed my own application, should I suggest to my client to buy Square?.

The client that asked me, in Mexico, did so because he had seen it in another restaurant. I assume then that it can be done. I was asking for some help on the "basics" where to start from.

[alogrep 0]

Embarcadero istself claims a

"Rapidly Deploy Blazing Fast Payment Solutions On Windows",

https://blogs.embarcadero.com/rapidly-deploy-blazing-fast-payment-solutions-on-windows/

but when you try to access the site it returns a 404 error. 

https://getitnow.embarcadero.com/InPay-20.0.7582/ 

[David Schwartz 426]

5 hours ago, alogrep said:

Hola David.

The field is the subject and the content of the post: E-Payment processing software for Delphi.

Perhaps is not the right wording, but what I was trying to get suggestions/hints about is how to allow a POS application to process a payment made with credit/debit cards. I found something, for example Stripe and a Delphi wrapper (https://github.com/gmurt/ksStripe).

It appears that one could add that payment processing library to an application. 

I do not intend to develop myself a Stripe-like software, but use it or something similar in a Delphi 11 app.

I have developed my own application, should I suggest to my client to buy Square?.

The client that asked me, in Mexico, did so because he had seen it in another restaurant. I assume then that it can be done. I was asking for some help on the "basics" where to start from.

It's not hard to add payment processing to anything using a 3rd-party API or a turnkey solution. I asked what country you / your client are in because security issues will vary.

 

I work with websites that have payment handling integrated from PayPal, Stripe, and others. They have mature solutions that aren't problematic. I haven't investigated using them with a Delphi app, but the issues are probably similar.

 

Integrating a POS terminal from a payment processor can be problematic. I've been involved with it using Delphi at several places, and while it's a PITA for a company, there's no way I'd want to do it myself. 

 

What I'm trying to say is there are literally dozens of turn-key solutions you can choose from that put you in the role of being a VAR -- Value-Added Reseller. That may not be as much fun as writing a bunch of Delphi code, but it's very profitable and your goal is to understand enough of the tech side to keep them happy while charging them a monthly maintenance fee -- without having to do any programming. 

 

Again, Square and Clover are two popular POS vendors with turn-key systems that you simply need to upload files and menus and text content, adjust some settings, and you're ready to go. They may even have a web portal you can use as well. 

 

I'm a programmer ... I love designing and building software. But over the years there are things that I simply don't want to do for various reasons, and integrating code into payment processing and health-care systems are two of them. The regulations here in America are simply too burdensome for my tastes. Where you're at, it might be different.

 

I'm personally looking into doing something obvious in the realm of bio-feedback, and there are products on the market that would make perfect sense for the vendors to have already done this, and it's puzzling to me why they have not. Someone suggested it may be due to FTC regulations that make it nearly impossible to mention anything about what to expect without having them nail you for making "medical claims". I've yet to dig into it, but the fact that nobody in the market is going in this fairly obvious direction makes me wonder if it's for regulatory reasons. 

[alogrep 0]

David.

1. As for the country, I did write "The client that asked me, in Mexico,...."

2. I think there is a fundamental misunderstanding caused by the word POS. I never meant POS terminals. I mean a POS application: where the waiter enters the order. At the end, when the customer pays the cashier scans the credit card with the bank provided terminal, and then has to duplicate the data entering in the database of the app (e.g "payd by visa").

He would like to enter or read  the credit card data (in some ways, maybe even with  some type of scanner) directly in the application  (that would send the data to a real payment-processing site on the web), so to avoid duplication.

If something like this is not possible, I will tell my client "sorry, that is beyond my reach".

Edited June 13, 2023 by alogrep

[FPiette 383]

Maybe reading this documentation would help you : https://redirect.jforce.be/api/v1/doc

This is probably not exactly the same in your country but you've got the idea about how it works when connecting a payment terminal to your POS application.

[alogrep 0]

Thank you very much, FPiette.

I have two questions, if you will

1. The customer (the restaurant) to use this type of API requires https on the PC (server) in the restaurant?

2. Aside from entering the credit card data manually in the POS App, are there ways to scan/read these data and send them to the API?

[FPiette 383]

3 hours ago, alogrep said:

Thank you very much, FPiette.

I have two questions, if you will

1. The customer (the restaurant) to use this type of API requires https on the PC (server) in the restaurant?

2. Aside from entering the credit card data manually in the POS App, are there ways to scan/read these data and send them to the API?

Look at the examples in the document (https://redirect.jforce.be/api/v1/doc/examples).

Note that this API is probably not available in Mexico. You have to contact the companies or banks which are providing the payment terminal. They surely have a similar (if not the same) API.