Android Question Mobile payment application?

[netsistemas]

First , I go to read this:​

Mobile Payments Library

Hello everyone, This app lets you add in-app purchases from your Basic4Android application. You are able to pay with Paypal, creditcard, etc. The library is from ZooZ, not the one from PayPal!. It is a very to use library with a few functions. All transactions, etc are done by ZooZ. ZooZ is a...

www.b4x.com

--

You see viable to develop a payment application for the mobile.

The basic idea is to be able to activate or deactivate an APP to make payments.
Also implementing GPS to know when and where you have used it.
Being able to disable it (remotely would be easy, using firebase messages).

With others words:
The idea would be that we assign a card to a user and he has it to pay. The data that we can about the payment would be recorded, such as (GPS position, instant, Amount, Alias of the establishment to which it is paid...) when the worker no longer needs it, we deallocate it from our ERP.

 

[Andrew (Digitwell)]

Who is your payment processor?

I have developed code for STRIPE

[B4X] [B4XPages] STRIPE Checkout - Credit card and Apple Pay

Attached a project which demonstrates how to accept a STRIPE Payment within your app. It is based on the information on this page: https://stripe.com/docs/checkout/integration-builder On iOS it also allows the use of APPLE PAY. Unfortunately, Google Pay does not seem to work for me, not sure...

www.b4x.com

and @MarcoRome has developed something for PAYPAL

[B4X] Online Payment with PayPal

Hi all. In Attached an example on how to use paypal for online payment in a simple way for B4X ( B4A - B4i - B4j ) In the example it is possible to enter any active paypal account, so you can also make payments on different paypal accounts. For each transaction, it will return if the transaction...

www.b4x.com

Is this the sort of thing you are looking for?

 

[MicroDrie]

There is currently no web site live with the name zooz.co.

 

[netsistemas]

Zooc.coM

Andrew:
I'm afraid not

The application to be developed would be to PAY.
Let's imagine a company that has 10 employees who eat out.
When they go to a restaurant, they currently pay by credit card.
The idea is that they can press PAY.
The truth is that according to what is written, I don't even understand how it could be done. It is not only a development problem, but for example, that who pays, must have a credit card. Otherwise, anyone could pay without a card.
I will talk more in depth with the client.
The final idea is to know who, where, when and who has paid.
A kind of GOOGLE PAY with better tracking and remote activation and deactivation.

---
Spanish:
me temo que no

La aplicación a desarrollar sería para PAGAR.
Imaginemos una empresa que tiene 10 empleados que comen fuera.
Cuando van a un restaurante pagan,actualmente, con tarjeta de credito.
La idea es que puedan pulsar PAGAR.
La verdad es que según lo escrito, ni yo mismo entiendo como se podria hacer. No es solo un problema de desarrollo, sino por ejemplo, que quien paga, debe tener una tarjeta de credito. Sino fuera así, cualquier podría pagar sin tarjeta.
Hablaré mas en profundidad con el cliente.
La idea final es saber quien, donde, cuando y el que ha pagado.
Una especia de GOOGLE PAY con un mejor rastreo y activación y desactivación remota.

 

[MicroDrie]

It is not only a development problem, but for example, that who pays, must have a credit card. Otherwise, anyone could pay without a card.

A credit card is just the implementation of the line "you have some of me and know some of me", just like a one-time code list to use or a one-time password calculator. All things that are not usually considered friendly.

If you look at that rule with a smart-phone, then only the unique IMEI number comes into consideration, because the SIM card can be cloned. If you take measures to deal with theft of the phone and you can guarantee a very good security of sending the IMEI number encrypted with a key that you only agree with the user of the app, you would in principle, with many buts , don't need a credit card.

If you opt for this, you must have a good measure against things such as keyloggers, etc. that cannot encrypt the unique IMEI number. Furthermore, with a financial limit you could also limit the risk of the PAY application. From a technical point of view, a lot is possible, but the question is whether this technique can also be successfully used to crack or protect the PAY app.

 

[netsistemas]

On my phone, I have google pay, with a credit card linked. When I go to pay at a site, instead of paying with my card, I pay with my mobile.

As a solution, it would be as simple as this application could only be opened by a user with a password. That will indicate what money is going to be paid and when (and from where via GPS).
This Google Pay enabler application could disable it without problem using FIREBASE or another technique (remote database and prior consultation).
This would be an approach, but I don't know if there is an API that enables payment via NFC from google pay.
What I have searched for, speaks of GOOGLE PAY API, but its purpose is for other purposes.

 

[MicroDrie]

The location of a payment is not part of the payment transaction for financial processing (perhaps for internal control and security) and will therefore not be passed on to the user or PAY app infrastructure.

But why not have the PAY app request the GPS location and send it to the administrator on the basis of a successful or unsuccessful transaction report in both cases?

The advantage is that that solution is separate from and works with every financial service provider with any kind of solution that you can choose in complete freedom.

 

[Andrew (Digitwell)]

Zooc.coM

Andrew:
I'm afraid not

The application to be developed would be to PAY.
Let's imagine a company that has 10 employees who eat out.
When they go to a restaurant, they currently pay by credit card.
The idea is that they can press PAY.
The truth is that according to what is written, I don't even understand how it could be done. It is not only a development problem, but for example, that who pays, must have a credit card. Otherwise, anyone could pay without a card.
I will talk more in depth with the client.
The final idea is to know who, where, when and who has paid.
A kind of GOOGLE PAY with better tracking and remote activation and deactivation.

---
Spanish:
me temo que no

La aplicación a desarrollar sería para PAGAR.
Imaginemos una empresa que tiene 10 empleados que comen fuera.
Cuando van a un restaurante pagan,actualmente, con tarjeta de credito.
La idea es que puedan pulsar PAGAR.
La verdad es que según lo escrito, ni yo mismo entiendo como se podria hacer. No es solo un problema de desarrollo, sino por ejemplo, que quien paga, debe tener una tarjeta de credito. Sino fuera así, cualquier podría pagar sin tarjeta.
Hablaré mas en profundidad con el cliente.
La idea final es saber quien, donde, cuando y el que ha pagado.
Una especia de GOOGLE PAY con un mejor rastreo y activación y desactivación remota.

Thanks for the further explanation.

Whatever the form of payment, the receiver has to be willing to accept that format, even though the payment is ultimately taken from a credit card or bank account. The payment method is only a fancy wrapper.

For this to work, your new app would have to be accepted as a trusted payment method.

The truth is that according to what is written, I don't even understand how it could be done. It is not only a development problem, but for example, that who pays, must have a credit card. Otherwise, anyone could pay without a card.

I can see you have already recognised this as being a significant problem