If a server is already listening to Real Time Developer Notifications what’s the benefit to also poll the Voided Purchases API?
The docs say:
Note: Unlike other order-related data sources, the Voided Purchases API includes purchases that are charged back by payment processors. Therefore, you might see inconsistencies between the information from this API and information from other order-related data sources.
This is too vague to draw any conclusions. Does that mean there are scenarios in which a subscription is invalidated which doesn’t trigger a RTDN and is only visible in the Voided Purchases API?
Google Developer Support clarified that the Voided Purchases API is only an addition for investigative / preventive purpose to counter refund fraud. For example, a user who subscribes and after a short time triggers a charge back, therefore having used an entitlement for free.
The API is not required to track subscription state, as a refund (like any other cause) triggers a RTDN.
You may use the Real Time Developer Notification (RTDN) to track any changes on the status of the user's subscription entitlement. Please note that the subscription is immediately revoked when the purchase has been charged back, you can refer to this link for your reference.
Additionally, you may still use the Voided Purchases API as part of your double security, and track the user's behavior to prevent refund abuse on your app.
Related
Goal: Allow a user on my website to pay another user(merchant) for a service via either PayPal or Stripe. I would like to take a percentage of the purchase amount and the remaining percentage would go to the merchants account.
I've successfully added both Stripe and PayPal to my Django app, and successfully integrated a payment portal, but the default use-case appears to be for the user to send a payment to owner of the website (owner of the paypal/stripe account) via a client ID. For paypal, I figured out how to specify the payee as the merchant, rather than myself, but there is still not a clear way to split the payment. I would not like to accept 100% of the payment and then pay the merchant. The only payment I should receive is the percent of the payment at the time of the transaction..
Is it possible to implement this type of payment schema through Stripe Merchant onboarding? The only route to achieve this through paypal as far as I can tell is PayPal partnership (paypal marketplace), which is for larger businesses.
Split funds from a single charge between different sellers using Connect
Connect
Stripe does not support the splitting of funds from a single charge
among multiple sellers for compliance reasons. As a platform using
Connect, you will need to ensure that there is still a one-to-one
relationship between a charge and one of your connected accounts.
PayPal User Agreement
4.5 No Surcharges. You agree that you will not impose a surcharge or any other fee for accepting PayPal as a payment method. You may charge
a handling fee in connection with the sale of goods or services, as
long as the handling fee does not operate as a surcharge and is not
higher than the handling fee you charge for non-PayPal transactions.
You will have to be the middleman and take payment, split it and then send the rest to the paypal user or make two charges, 1. The cost 2. Your fee.
The only route to achieve this through PayPal as far as I can tell is PayPal partnership (paypal marketplace), which is for larger businesses.
That's correct. Without that type of partnership, you would need to accept the whole payment and use something like Payouts, which of obviously does not meet your requirement of only accepting some percent.
(There was a very old way to do it -- Adaptive Payments Chained Payments, but you can forget it ever existed; no longer ever available)
I suppose, technically, the deprecated EC Parallel Payments is still open and "usable", but that's an observable split and designed for use cases like paying for a Hotel and Airfaire at once. Really not good for marketplace use, and it's also quite old and may go away soon due to that deprecation. I would not recommend using it for anything, much less marketplaces -- just covering the bases.
After I done integrating my apps with Facebook local currency payments, I asked my colleague to purchase in-game items and later dispute the transaction for testing purpose.
I did receive the real time update on dispute, but soon after 4 seconds, I receive another update that Facebook had initiated refund.
I thought developer should be given 72 hour to handle dispute and verify the dispute is legitimate?
Here is what the doc says:
As mentioned earlier on this page, Facebook's philosophy regarding
payment disputes is that we will handle all disputes that imply that
the user is requesting a full refund of the transaction (i.e. the "I
accidentally purchased an item I do not want" option). On the other
hand, if the user request is aimed at receiving the item or in-app
currency that they've purchased, we will route the dispute to the
developer (i.e. the "I didn't receive the game item(s) I purchased"
option).
So I guess there is no 72 hour disputes (and no corresponding callbacks) when user selects "correct" options.
I am developing an online ticketing system for events (like concerts). A basic part is a seat chart where the visitors will be presented the available seats/tickets to choose from. Once they make a selection, the system immediately tries to reserve the tickets for 10 minutes (by entering the ticket IDs into a table where ticket ID is key).
Only if the reservation was succesful, a paypal button is presented to make the payment.
All this works fine. Ticket Reservation is not a problem for me. I can handle that in my system. But once paypal comes into the game, things get difficult.
The Problem:
If the user for some reason spends a lot of time in Paypal (more than 10 minutes), the ticket reservation on my website will expire, allowing the tickets to be bought by another visitor, which might happen before visitor 1 makes the payment. Visitor 1 does not see any of this because he is still in paypal... At some point in time, he will manage to make the payment (e.g. after 15 minutes), which will perfectly work because paypal does not know anything about expired reservations.
In the end, I might have two visitors having paid for the same ticket/seat!
How can I prevent that from happening?
How do you handle race conditions if two systems are involved and one of them is out of your control?
My thinking was: Actually a check should be made right before the payment takes place, but of course I don't have control about what happens in paypal!
I know I can use Paypal's IPN and such, but this only happens AFTER payment which is too late.
Alternatively, it would be great if paypal asked me through API to confirm a payment. Then I could say "no" in case the tickets have been sold to someone else. But I don't think this is possible with paypal.
I'd recommend using Express Checkout. Express Checkout allows you to control when the payment happens, because you'll fire off an API call to PayPal to actually process the payment.
The other possibility you can look into is using an authorization instead of a sale transaction. That way, if another buyer takes the seat, you can void the authorization, and the buyer won't get charged. (PayPal will probably charge you for the voided authorization, however.)
One solution as Matt Cole suggested is to use 'authorization' instead of 'sale'.
You can do this by setting 'intent' to 'authorize' instead of 'sale' ({intent: "authorize"}) in your calls to the Paypal API when you're creating a Paypal payment. Once the customer approves the transaction, it is up to you to authorize this transaction by capturing the payment.
I'm integrating with Authorize.net's ARB API. Authorize.net processes their transactions at a certain time everyday, so when people create a subscription, their transaction is not real time.
I am creating a subscription based model, does their API tell me whether their CC has been processed? Or should I put a delay on the access to my site until they have processed all the ARB transactions that day.
Thanks in advance!
You should be charging their first subscription payment via the AIM API. This will give you instant feedback as to whether or not the payment was good. Assuming it was successful you then can use ARB to create their subscription by setting the start date to be the date of their next scheduled payment.
This serves two purposes:
If the card is bad you know immediately and can have the user provide a new card while they are still on your website. Once they leave your site it gets much more difficult to get them back to correct it.
You can give them instant access without worrying about whether or not their card is approved or not.
FYI, you can use Silent Post to determine the status of payments made via ARB.
I've been tasked with setting up a society's website. I'm a full time Django (at al) web developer so I was happy to take on the task.
Going through the specs, they want to control memberships so that all applications need a "second" (read: sponsor, referee, etc) and then they need to pay a subscription fee to be part of the club.
This club has a number of events with variable ticket prices for lunches and talks to name two. Only members are allowed to see the price per ticket and therefore only members are allowed to buy the tickets.
I had originally planned on farming the event management off to EventBrite and pulling the upcoming events back to the website through EB's API but this members-only constraint looks like something EventBrite can't do.
Then there's processing members subscriptions. I had hoped to allow anybody to register a django.contrib.auth account but leave subscription payment offline but the client would be happier if they could mark accounts as "members", store the subscription data in the database and let the members pay online.
Like with EventBrite, I was hoping I could store rough membership data (whether or not they're allowed to subscribe, a unique token for the user on the API service, their level of membership and their membership's expiry) and there'd be something I could post users off to to process their subscription payment.
I basically don't want to touch any payment systems. Even something as simple as Paypal+IPN is something I'd rather not do (I can and have in the past on other projects) but it's the layer of management that I'd have to build around it (messaging members, creating recurring events, etc) that I'd like to farm out to a third party... Even if they do want an additional percent of the payments processed.
Do any of you know any suitable APIs that cover membership or events or both?
Or is this so complex that I should give up hoping for external help and just knuckle down and do it myself?
I think the google search you are looking for is online membership management. I don't know if any of them play particularly nicely with Django/python, but some of them do include APIs. Almost all of these are companies that charge, either for the system, or on a per-user basis.
If you don't mind installing something yourself, CiviCRM is a free, open source solution that I found with a bit of googling. It's integrates with either Joomla or Drupal (so probably PHP-based). You'd have to put the payment processing in yourself, but it does support payments using PayPal which would take handling payments mostly out of the equation. If you can, choose PayPal Express rather than PayPal Website Payments Pro since you may need to be PCI-DSS compliant to use the latter.