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.
Related
I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).
When a user purchases a subscription, I store the receipt on completed transaction on the server alongside a key to identify the user the receipt belongs to. When the app needs to check if the subscription is still active, it queries the server, the server validates the receipt with Apple and returns info to my app wether the subscription is expired or not.
Now the question is:
When the response returns a latest_receipt/_info field, the server should take that receipt and replace the old receipt for future verifications. What happens if there is a gap in the subscription period (e.g. the user subscribed for 1 month, then cancelled, then subscribed again) or the user changed the subscription type (e.g. from 1 month to 3 moths)?
Will the original receipt still validate, and return a latest_receipt/_info field, or do I need to store a new receipt from the new transaction?
I'm really confused on this auto-renewal thing right now, so I'm not even sure if my validation process is right.
I'm not sure about all possibilities you have to verify receipts and maybe it works your way, but we did slightly different and by that don't face your problem.
We store all the receipts on device-side (note that auto-renews result in new receipts as well). Whenever verification is necessary we post the latest device-stored receipt to server where it is verified by calling iTunes. After that the server responds to device about user's rights.
I think that's the way Apple recommends it (or at least this is how I understood Apple's docs).
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.
Been googling all day, reading numerous PDF's and still getting confused with the concepts of sending data to Payway system from Westpac (a bank in Australia). They offer access via API but also give access via what they call "NET."
The way I understand is that when client want to pay on my website, in case of NET, client gets to the page (hosted by a bank or hosted by me) where is provided with form to enter credit card info details. Then this form is submitted via normal POST call to Payway's specific https address. It is processed then and browser returns to the URL I specified as one of the parameters I sent in hidden field.
In case of API story is similar, so user receives form, fills in the data and then data is send to my backend (not Payway's). My backend then calls payway API with data provided and once answer received returns confirmation page to the client.
Is my understanding right? Please explain as I have a feeling I am missing something basic here.
There are a number of different ways to interact with PayWay Net, depending on how much control you want. The simpliest way is this:
You create a HTML format containing fields with certain names. This form is served up by your website, but when submitted goes to the PayWay website. You can add to this your own hidden fields and information fields.
Your user enters some details and clicks Submit.
Your user's browser submits the form to PayWay. PayWay validates the values and displays a page asking for credit card information (over https)
The user enters the credit card details then confirms the transaction.
PayWay processes the credit card transaction
Optionally, PayWay can conduct a post back to your server indicating the status of the transaction so you can complete the order (called server-to-server payment notification)
Optionally, PayWay can redirect the browser back to your server (but do not use this to update yoru database)
There are also ways to fully customise the credit card input page and receipt page.
PayWay API is different. You install a piece of software on your server. When you want to conduct a credit card transaction, you invoke this piece of software. It talks over the internet to the PayWay server, conducts a transaction, and gives you a response. You could use this if you were writing a phone payments system, for example, as no browser is involved in the PayWay interface.
(Disclaimer: I work for Qvalent, developers of PayWay).
Your understanding is correct.
I've done a couple of Payway integrations and have always opted for the API solution so that users get a consistent experience and are not jumping between websites.
An odd thing about PayWay, is that while most payment gateways have 2 options.. a merchant hosted or server hosted, PayWay offers this pseudo-merchant hosted with their NET option using the token request. Credit Card details are taken directly on the merchant site and only redirects the confirmation momentarily to the server and then back. This would be great if a payway account worked universally with both NET and API.. but it seems an API account doesn't support NET methods. So if you want to accept cards on your site, the NET token method is pretty much eclipsed by its bigger API brother.
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