Is this processus to pay a user, reliable and safe? - process

I'm working on a project that require my application to pay the user to his paypal account when he asks it.
Here's how I did it so far:
The (logged) user goes to the Pay page that will list all his Payments (received or not)
He enters his Paypal email and his application (mine) password (for security)
The POST page get a list of all the Payments that have status="UNPAID" for that user and update the status to "WORKING" (to avoid the user to refresh the page before the whole process is done and resend the same amount of money)
We count the total amount to pay in that list (a simple for)
The amount is sent to Paypal via Paypal Adaptive Payment API (request: PAY)
The response is checked, if completed, the list status is set to "COMPLETED", if not, the list is reverted to "UNPAID" (the SQL update is made via a WHERE id IN(x, y, z) in case a second Payment request has been made during that time.
A message is then displayed to the user
But I need your help, I'm in front of one risky problem I'd like to avoid, and I would know how you would do:
If the user hit refresh on the process page, I don't want to send him twice (or more) the amount (The "WORKING" lock is here for that, but what happens if the user hit refresh before I set the lock ?)
Rare possible: what happens if the user hit f5 after the lock "WORKING" is made, but before the request to paypal, and a new payment is received. By following what I did, just one item (the new) would be get and set to WORKING, but all others previous payment would be losts
How would you do? What is the best way to make it to be 100% reliable?
Thanks for your help
Note:
The steps between 4 to 6 is made via a PlayFramework jobs, called with now() and awaiting() the result

you can:
prevent double post via JQuery
use the checkAuthenticity() method to validate the request
do a GET redirect after processing the POST (so they can't submit the same 2 times even by mistake)
do the payment processing asynchronous (see below)
For the payment, instead of calling the job, set the id's of payments in a queue (or table in the database) and a job that runs once per minute that processes that table if it has some data. When the user does the POST you redirect to a page that says that you are processing the payments and will notify if there is some issue. You can notify the user later via a UI warning using comet or via mail.
That way you don't link the request to the processing, and you won't have threading/racing issues, as well as being able to detect stale requests (payments already done) if you do a sequential processing.

Related

Google transactions is waiting for userInput and then leaves the conversation

I am trying to create an action for the google assistant using google transactions, when I take it out of Development Sandbox to allow real orders and transactions, it will prepare the order and the receipt. Then it is supposed to check if the order will be accepted or rejected and wait for the user to say that they want to make the order, however, it waits for the user but then closes the action straight away and doesn't let the user input anything.

A good way to check if the payment form was left off in between

We use PayPal to accept donations on our website. The problem we're facing is usually this happens that a user clicks on the pay button on our website but then for some reason drops from PayPal.
Is there a way through the PayPal API we could check that the user for some reason left off the transaction or maybe his transaction was denied.
No there is not; keep track of that drop off yourself if they don't come back or you don't get a resulting transaction.
If you are not using an API to accept the donations, then to be notified of resulting transactions you can use Webhooks. A parameter you can use for reconciliation is custom, which can be set at the moment the user clicks 'Pay' and you redirect them to PayPal.
(But if you are using an API, then the API is your notification already)

Paypal ipn processing and dropdown option/price buttons logic

I read lots of post from various sites including paypal documentations. But I have some quesitons wihch I couldnt solve those. One of them is that how to design the codes after receiving the ipn message. Ofcourse I make my code I am able to optain and process the variables of message. like payment status and I am able to save them into database. But the point is that how should I desing the code to control the payment to overcome my requirements. I know the post become long but I feel the need of this explanation. So I have a site which works with membership with payment. Site is check after login the membership trial is expired or not if it is expired it shows a div in fornt of the site wihch includes the paypal buttons and redirect to paypal payment screen when button is clicked. User shodul have ability to choos membership period like 6 or 12 mounths (by dropdown paypal button). When the user finalize his payment ipn is trrigerd and I get the datas but all my members dont have to have a paypal account so they can use therid credit card directli and if I understand correctly the transfer of money can take some time to be recevied by me. Which time interval I should set the members approved flag is true ? I am confused about this. If I approve him after ipn is sent is there a possibility an error can occure while transferring me. How the process works.
other problem is the dropdown button. when I set option/price button when I click the button an error page is shown after redirecting to my selling page. It does not redirect to the payment page.
Realy sorry for my long post but I dont know how can I descirebethe situtation in a short way
If you need to wait until funds are available, you should test the value of "payment_status" in the verified IPN message for "Completed".
An eCheck can take from 3-5 days for collection (sometimes longer; you can see the estimated hold time in your account) and has payment_status="Pending". Once collected, you will get another IPN message with "Completed".
Note that the user never sees the IPN process. Normally you set up the conditions (in a table or something that is persistent enough), then send the user to PayPal. When the user comes back from PayPal, your code (at the "return_url") checks the table to see if Payment had completed successfully (perhaps a flag, which was set by your IPN handler code that is called by/communicated with PayPal when the user leaves PayPal gracefully).

How to solve the problem of not being informed of successful payments by the 3rd party system used by my website?

I have a subscription based website that interacts with a 3rd party system to handle the payments. The steps to process a new subscriber registration are as follow:
The subscriber enters his/her details in the subscription form and click on the submit button.
Assuming the details specified are valid, a new record is created in the database to store these details.
The subscriber is then redirected to the website of the 3rd party system (similar to paypal) to process the payment.
Once the payment is succesful, the 3rd party website then redirect the subscriber back to our website.
At this time, I know that the payment was succesful, so the record in the database is updated to indicate that payment has been made successfully.
A problem that I have found occurring quite often is that if a subscriber pays but does not complete the process correctly (e.g. uses the back browser, closes the window), his/her record in the database doesn't get updated about this. Accordingly, I don't know if s/he has paid by just looking the record and need to wait for the report from the 3rd party system to find this out.
How do you solve this problem?
PS. One of the main reasons to store their details into the database before the payment process is done is so they can come back to complete the payment without re-entering their details again. For example, when their credit cards were rejected by the 3rd party system and they need to sort this out with their financial institution which may take a while.
The third-party payment system should inform you of the successful transaction regardless of what the user does.
For example, in PayPal, an IPN (instant payment notification) is sent to your server as POST data to a URL that you specify. Your server then verifies with Paypal that the transaction is genuine, and if so, updates the database record to indicate the subscription is valid. At a point in the future, PayPal may or may not then redirect the user back to your website. (The "may not" can occur in cases such as the user closing their browser, hitting Back, or jumping to a new URL)
Note that this "conversation" between Paypal and your server is independent of the user's session - it is a "private conversation" between you and PayPal about that user's transaction.
Obviously there can be communications outages and server failures, so if Paypal does not get the validation request from your server immediately it will periodically send retries to your server to ensure that the transaction is eventually completed.
If your payment system doesn't have at least some basic mechanism for ensuring transaction reliability, then choose a different provider. Chances are that they do, but you will have to implement things correctly on your server to be sure that the system works properly.
P.S. It is quite normal to require a user to log in (and thus be registered in the database) before they initiate any financial transaction. You need to gather all the relevant information before they go to purchase, as after the purchase you have no way of guaranteeing that they will return to you to provide any further information.

Getting status on canceled/expired credit cards for recurring billing with authorize.net

We're setting up a system that will use the XML API for Automated Recurring Billing with Authorize.net.
It looks simple enough to set up a recurring billing. But we have two features that do not seem obvious
* providing customers with details on individual payments
* providing notification to customers of expired/canceled cards
Anyone familiar with a mechanism to retrieve this info in automated form? We're considering
* just listing out assumed payments based on our own calculations the start date
* emailing customers based on the expiration date of the ards
But I'm stymed on how to figure out when a transaction failed due to canceled card (and automatically notify the customer).
Can anyone comment on how they handled this issue when implementing a subscription-based service based on Authorize.net?
Authorize.Net has recently published a new ARB method "ARBGetSubscriptionStatus".
You may now easily query the status of a previously submitted ARB subscription without the need to depend on the "Silent Post Method".
Example:
<?xml version="1.0" encoding="utf-8"?> <ARBGetSubscriptionStatusRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication> <name>mytestacct</name> <transactionKey>112223344</transactionKey> </merchantAuthentication> <refId>Sample</refId> <subscriptionId>100748</subscriptionId> </ARBGetSubscriptionStatusRequest>
You want to use Authorize.Net's silent post feature. It will notify you of all payments made through their system including declines and expired credit cards. Your script will then be able to suspend accounts and/or notify your customers that their payments has failed.
See these link for more info:
Handling Authorize.Net ARB Subscription Failures
All About Authorize.Net’s Silent Post
Handling Authorize.Net Silent Post with PHP
You need to use the Silent POST URL
ARBGetSubscriptionStatusRequest will not work. If the first transaction (or first transaction since the ARB profile was updated, either via API or manually) fails, the status of the subscription is set to suspended. Otherwise, the status of a subscription does not change when a transaction declines or a card expires.
Using the Silent POST URL, you'll be notified of successful transactions and you can use them to update your data such as tracking a next payment due date/expiration date. You can then run a cron job and if this field has not been updated, you will know that the card was cancelled or expired.
In the event that it is still an active card but gets declined, you'll get notified as such at the Silent POST URL