I’ve mentioned before my desire to replace eSellerate for InApp purchase (without license key generation) and was wondering whether anyone had any examples of how to integrate these into Xojo applications ?? ( since their websites don’t mention Xojo or RealBasic/RealStudio at all )
What do you want?
E.g load shop page in a HTMLviewer?
Yes, exactly, as a modal viewer with SSL connection but upon purchase complete use api to connect with purchase result to get order details and list of items/SKUs purchased so I can then download in app purchased plugin(s) or unlock embedded plugins etc.
I am using Paddle for about 10 months now. Very happy with it and the customer support is great.
Paddle offers several ways to integrate selling your apps.
[quote=316706:@Christoph De Vocht]I am using Paddle for about 10 months now. Very happy with it and the customer support is great.
Paddle offers several ways to integrate selling your apps.[/quote]
Can you point me to any Xojo examples or Xojo SDK integration links please?
There is no Xojo SDK. But you can use a HTMLviewer to display the Paddle checkout window.
Ahh, I see. So how can you know that the purchase is complete and interact via api with Paddle with regards to the just completed purchase to retrieve information aout the order?
So I did it this way with Fastspring…
When my app is purchased on Fastspring it does a POST call to a small web app I have created (under Laravel’s Lumen. If the all the POST data validates including the token, it then calls a small Xojo Linux Console app that uses the MBS Registration plugin and then simply returns a new license key tied to a few parameters. That gets sent back to Fastspring and the customer.
You could probably write the web app in Xojo and combine the web/console gateway, I just chose to do it that way as I had plenty of spare capacity on an AWS box of mine that runs a few laravel apps under Forge control.
Seems stable enough.
Upon completion you can have Paddle redirect the HTML view to page of your choice.
Take a look at our HDRtist NX as this application uses Paddle as the payment system. http://machdr.com
You could also poll the list of transactions here https://paddle.com/docs/list-transactions-api and fire off your licence code if you dont want to provide a webhook.
You could also parse the HTML (see https://forum.xojo.com/38700-accessing-html-source-in-htmlviewer) and do something with the response from the HTMLViewer.
Having taken a brief look, their API looks quite far reaching so there should be a number of vectors available to you.
Thanks, Richard. This seems like a good solution.
Thanks, Sam. Does Paddle allow you to add multiple items to a cart or just work on a product by product basis for each purchase?
Thanks, Julian. This could prove helpful also.
With Paddle, it is also easy to trigger a php script when a successful payments has been done. That way you can create your own license key gen.
A couple of follow-up questions:
-
Can anyone confirm whether Paddle and FastSpring handle European VAT correctly?
-
How do these systems handle PayPal transactions with delayed IPN notifications due to type of payment? For instance, an e-check payment can sometimes be delayed for a few days so even if the PayPal transaction completed successfully, theoretically the HTML viewer should not handle the response parsing in the normal way and always unlock the app or plugin since funds may not have actually cleared and still could be reversed if there were insufficient funds in the account.
[quote=316862:@Denise Adams]A couple of follow-up questions:
- Can anyone confirm whether Paddle and FastSpring handle European VAT correctly?[/quote]
Yes. Paddle handles VAT for you. No need to mess with MOSS anymore.
Important note: Only Paddle can fix point a price in Eur. Thats a huge reason why I use Paddle and not Fastspring. Fastspring always uses USD as the main currency. So if you are a developer living in EU that’s a huge no-go.
[quote=316862:@Denise Adams]
2. How do these systems handle PayPal transactions with delayed IPN notifications due to type of payment? For instance, an e-check payment can sometimes be delayed for a few days so even if the PayPal transaction completed successfully, theoretically the HTML viewer should not handle the response parsing in the normal way and always unlock the app or plugin since funds may not have actually cleared and still could be reversed if there were insufficient funds in the account.[/quote]
Paddle handles this perfectly for you. No need to do any actions.
Why don’t you make a free account at Paddle and do the tests yourself? You can easily emulate payments etc…
Thanks, Christoph. I will look into that. Still confused about PayPal e-check handling though. On my web site if this happens I have to manually handle the order fulfillment/registration a few days later when the funds have cleared, so I assume the same would be the case with any in-app payment provider unless card is the only form of payment. Otherwise how can you unlock a product if you do not know whether funds will definitely be received?
As said, Paddle with handle the PayPal e-check for you. You will only get a notice when the e-check is fully cleared. Plain simple - no rocket science. 
I still stay with Share-It. They can do Euro and provide me the address.
Thanks.
I think you misunderstand me. If you’re dealing with an in-app transaction and need to handle the response right there and then (as to whether or not to unlock or not unlock app) then delayed payment doesn’t work. Nevermind though, I will check them out. Thanks.
Because the echeck hasn’t cleared, Paddle wouldn’t tell your app to activate.
You will still need to implement some kind of activation system that doesn’t require an in-app purchase to handle instances like these. I would also recommend it because there are users out there (I happen to be one of them) who will not buy something directly inside an app. If I can’t pop it out into a browser, I’m not buying.
[quote=316982:@Tim Parnell]Because the echeck hasn’t cleared, Paddle wouldn’t tell your app to activate.
You will still need to implement some kind of activation system that doesn’t require an in-app purchase to handle instances like these. I would also recommend it because there are users out there (I happen to be one of them) who will not buy something directly inside an app. If I can’t pop it out into a browser, I’m not buying.[/quote]
Thanks. Yes, I know some users don’t like in-app purchases and it is a consideration but sometimes you have to balance the number of customers you’d win for convenience of in-app purchase and instant activation and the “impulse” buy…and the ones you’d lose over security fears.