PayMoney - Secure Online Payment Gateway v4.3.2 Untouched

xaos said:

its useless unless u spend on it like 4000$ to develop functional site

Click to expand...

xaos said:

its useless unless u spend on it like 4000$ to develop functional site

Click to expand...

zak.bouhali said:

Possible explain more

Click to expand...

dnull said:

Let me check what I can help, I've most of things will be sharing soonly

Click to expand...

gordian said:

In a nutshell the script is a beautiful script. However, it's at best an advanced template which is demo ready but isn't ready for business else if you pay for some "add-ons" which are required to make your script ready for business.

Now these "add-ons" aren't available because the script Author always has to integrate them each time, upon request to each script (and also painstakingly upgrade them each time this process is necessary). As a result of this you most likely have as many variants of the integrations as there are customers, as many customers don't all require all the necessary "addons" at the same time.

As a result of this interesting scenario, you should at a minimum budget to spend $4,000 to get it fully functional and market ready. As is it's useful at best as a proof-of-concept app.

Cheers!

Click to expand...

zak.bouhali said:

Thanks for the interest and reply
Is there an alternative you recommend?

Click to expand...

gordian said:

There's a digital bank software by Viserlab but PayMoney has accomplished more than ViserLab's script. As for vivo and elab, they address a different use case.

The interesting thing is that for a while I was looking for the same magic bullet. It appears that a true market-ready script in that sector seems a tad elusive. It's my opinion that the reason why this unavailability persists is rather simple. The time and cost and complexity required to build such makes it unattractive given the few persons interested in such a financially regulated sector.

As you know, playing in the international remittance space oft requires licensing, but those are not the major issues. The issues in the real-world are that of having a script that the transfers can automatically remit value to the customers across continents, when those customers are using different gateways.

Transfers and remittance within the same gateway (eg PayPal to PayPal) is easy, but across gateways that's a challenge.

So the problem shows itself if you have say someone from India who wants to pay someone in the United States and the sender is willing to pay with PayTM and the recipient wants to receive with PayPal. As one is yet to see any script on CodeCanyon which offers the ability to handle such automatically, it means the admin has to manually authorise each transfer and make the transfers from the other account. Eg, receive the payment from PayTM and login in manually to his PayPal and transfer the money.

It would appear that whichever script you choose, because they don't come with the ability to handle automatic settlement, and for this reason alone, amongst others, in this world where the WorldRemits are able to perform automatic remittance and settlement in realtime, the chance that you're sleeping when in some part of the world a thousand users are screaming because their transfers are 8 hours late is a real problem.

And for this you now have to budget real money sometimes as much as $499 to $999 for each subtle customisation that improves the usability even minimally, and the more you customise the more you find newer subtle modifications to perform (eg limiting the transfer amount which should automatically remit, performing security checks, ensuring that a user hasn't made tens to hundred of little transfers to circumvent your security rules and limits, checking problem IPs, etc.

So essentially, it's at best a slippery slope which you only undertake to start if you truly have a willingness to continue along the rabbit hole no matter what challenges may come your way eg, factoring in 2FAs and how to handle automatic authentications and remittances from gateways that do not instantly settle into your account and for which there will be the expected chargebacks.

As you already know, in all, each customisation once paid for is non-refundable and mostly cannot be seen from the user interface, so you will most times nurse a coffee to sleep whilst asking yourself what next.

A starting budget of $4,000 as suggested by @cyrillebrice might get you out of the door... but a budget somewhat larger than that will be helpful to ensure you don't burnout.

Click to expand...

gordian said:

In a nutshell the script is a beautiful script. However, it's at best an advanced template which is demo ready but isn't ready for business else if you pay for some "add-ons" which are required to make your script ready for business.

Now these "add-ons" aren't available because the script Author always has to integrate them each time, upon request to each script (and also painstakingly upgrade them each time this process is necessary). As a result of this you most likely have as many variants of the integrations as there are customers, as many customers don't all require all the necessary "addons" at the same time.

As a result of this interesting scenario, you should at a minimum budget to spend $4,000 to get it fully functional and market ready. As is it's useful at best as a proof-of-concept app.

Cheers!

Click to expand...

cyrillebrice said:

All the scripts that offer the kind of service that is related to finances are only rough drafts because for the best use, you just have to study their structures and modify everything as you see fit to have something that meets your expectations. (PayMoney, BoomPay, PayLab, Pay Need, ViserBank, Vivo and all the others are all draft scripts to which you have to adapt yourself)

Click to expand...

johnwick said:

Most of the scripts on Codecanyon are not production ready, it's like developers don't want the buyers to use them & make something out of it.

I believe the authors just want to use codecanyon to keep the buyers of scripts in a loop of updates with intentional bugs.

Click to expand...

gordian said:

There's a digital bank software by Viserlab but PayMoney has accomplished more than ViserLab's script. As for vivo and elab, they address a different use case.

The interesting thing is that for a while I was looking for the same magic bullet. It appears that a true market-ready script in that sector seems a tad elusive. It's my opinion that the reason why this unavailability persists is rather simple. The time and cost and complexity required to build such makes it unattractive given the few persons interested in such a financially regulated sector.

As you know, playing in the international remittance space oft requires licensing, but those are not the major issues. The issues in the real-world are that of having a script that the transfers can automatically remit value to the customers across continents, when those customers are using different gateways.

Transfers and remittance within the same gateway (eg PayPal to PayPal) is easy, but across gateways that's a challenge.

So the problem shows itself if you have say someone from India who wants to pay someone in the United States and the sender is willing to pay with PayTM and the recipient wants to receive with PayPal. As one is yet to see any script on CodeCanyon which offers the ability to handle such automatically, it means the admin has to manually authorise each transfer and make the transfers from the other account. Eg, receive the payment from PayTM and login in manually to his PayPal and transfer the money.

It would appear that whichever script you choose, because they don't come with the ability to handle automatic settlement, and for this reason alone, amongst others, in this world where the WorldRemits are able to perform automatic remittance and settlement in realtime, the chance that you're sleeping when in some part of the world a thousand users are screaming because their transfers are 8 hours late is a real problem.

And for this you now have to budget real money sometimes as much as $499 to $999 for each subtle customisation that improves the usability even minimally, and the more you customise the more you find newer subtle modifications to perform (eg limiting the transfer amount which should automatically remit, performing security checks, ensuring that a user hasn't made tens to hundred of little transfers to circumvent your security rules and limits, checking problem IPs, etc.

So essentially, it's at best a slippery slope which you only undertake to start if you truly have a willingness to continue along the rabbit hole no matter what challenges may come your way eg, factoring in 2FAs and how to handle automatic authentications and remittances from gateways that do not instantly settle into your account and for which there will be the expected chargebacks.

As you already know, in all, each customisation once paid for is non-refundable and mostly cannot be seen from the user interface, so you will most times nurse a coffee to sleep whilst asking yourself what next.

A starting budget of $4,000 as suggested by @cyrillebrice might get you out of the door... but a budget somewhat larger than that will be helpful to ensure you don't burnout.

Click to expand...

johnwick said:

Most of the scripts on Codecanyon are not production ready, it's like developers don't want the buyers to use them & make something out of it.

I believe the authors just want to use codecanyon to keep the buyers of scripts in a loop of updates with intentional bugs.

Click to expand...

Jg_selisa said:

Typical ***** Developer who try to stir customers away from Codecanyon for offline sales and end up loosing instead of winning. SMH

Click to expand...

dnull said:

Can you please explain more your comment whom you're trying to target??

Click to expand...

PayMoney - Secure Online Payment Gateway v3.1.0 tanks​

cyrillebrice said:

That's exactly it because at the beginning when we did not yet know their intentions, the Woocommerce plugin from PayMoney made us suffer we had to write our own Woocommerce plugin from PayMoney because we had noticed that we introduced a bug in PayMoney scripts for returned on a return url that does not work and even until today they still deliver the script with this bug

Click to expand...