I am looking into online stores to use internally at a company. They would like to be able to add credit to a users account as part of an incentive program.
I have started looking at Online store software, but am not clear as to which support store credit, or if it is a function of the payment module (ie separate issue).
The credit shouldn't be in the form of actual money (so it shouldn't be like putting money on a users paypal account), but credit which can be redeemed in-store.
You could implement this easily in Satchmo with the Giftcertificate-Module. You can assign a GiftCertificate an amount of money and the user owning this code can use it on checkout to pay. If the cart-amount is less, then the GC can be used afterwards with the rest-money on it. And if it isn't enough money on it, the user can pay the rest with any other payment method available.
Magento has this functionallity built into their commercial editions.
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.
I'm building a website to allow people to donate to a local charity quickly and easily. The charity allows direct donations, but it's primary function is to do "per mile" style donations, but with pull ups. In that past, they have collected the pledges ("I'll pay $1 per pull up"), then manual contacted people for payment after the event. This isn't very slick and very time consuming.
What I'd like to be able to do is collect a pledge and payment information, then charge people automatically after the event. From what I've seen, I should put a hold/authorization on their account, then capture it with the appropriate amount after the event. But reauthorizing will only allow up to 115% of the original, and I can't very well just authorize a large amount and let it sit for two months before reauthorizing and capturing it.
I know this can be done, but I haven't messed with this side of things before, and the REST API from paypal doesn't have an obvious solution. Is there something I'm missing? Should I be going about this a different way?
You can use reference transactions. I would recommend sticking with the Classic API for now, though. REST isn't as mature yet and doesn't have all the same functionality quite yet.
So in the classic API you would use Express Checkout and/or Payments Pro. You can process an original authorization and then simply void it, or use the card verification process with Payments Pro.
You won't need to capture an original amount, so you won't need to worry about the 115% cap on the capture.
Instead, you'll use the DoReferenceTransaction API to process any amount you need to at any time from that user's account account.
With Express Checkout you have to be sure to include a billing agreement in the setup. This guide outlines that whole process.
With Payments Pro you just do the original card verification / auth and then pass that auth ID into the DoReferenceTransaction API.
In either case, if you're working with PHP this PayPal PHP SDK will make all of the API calls very quick and easy for you.
Would I be correct in assuming that a user of my iOS app that uses CloudKit would not need to pay a monthly fee to Apple to use my CloudKit app? Apple just changed from annual to monthly for anything above 5GB for iCloud... or is it unrelated? I've been hunting around Apples development site and I cannot seem to find a reference for who gets charged a fee for use of CloudKit. WWDC made brief reference that there is a limit that can be reached and it seemed like they were indicating that the developer would have to pay Apple if their user base exceeded a certain point. If that's the case, a developer would have to be very careful to make sure they charge enough for the app. It could get expensive if there is a sudden increase in app use by a smaller number of users.
When you store data in the public database, then it counts as data for your app. If you store data in the private database, then it's counted at the user's account (now max 5GB for free). If you want to know how much data is available for free for your app, then have a look here: https://developer.apple.com/icloud/documentation/cloudkit-storage/
What options exist to facilitate payments to banks or credit card companies? Are there programmatic APIs for banks that, say, perform the same actions as paypal might? I'm looking for libraries or options that aren't through an existing provider; that could be developed on their own.
Basically, lately I've become interested in ecommerce and I'm wondering how the communication between a website and a bank or credit card company is made.
I've looked around a bit, but I'm not really sure about the terminology in the field; any resources you could point me at, or good books about the subject would be awesome. Thanks!
You get a merchant account with a bank, then sign up with a merchant processor like Cybersource or Litle. The merchant processor provides an webservice API to process authorizations, payments, credits, and voids. You implement the processor's API and then you can do online payments. They act as a go-between for you and the credit card company. You're not likely going to get permission to communicate directly with the credit card's network.
Maybe use this link as a starting point. This is cybersource's API documentation.
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.