I'm developing an app in Ruby on Rails where companies buy advertising campaigns. First they buy credits to their account on my site, then they buy the campaigns with the credits. The thing is the campaign is payed per view/click. A company reserves a budget of credits for each campaign and these reserved credits can't be used to buy other campaigns with. When a campaign ends and not all credits are used they will be un-reserved and available to buy more campaigns for.
How do I structure the models in the database and how to move/reserve/un-reserve the credits in order to periodically check for any credits that should be un-reserved in a background process?
Have a client/campaigns relationship. Each client has a number of credits. Each client campaign can withdraw credits from the client. As a campaign is viewed/clicked it withdraws credit from the client campaign.
A process periodically checks for lapsed campaigns. When it finds one, any remaining credits are deposited back to the client's main account.
All the money is kept in the company's account all the time. The goal is then to dynamically calculate how much of the funds that are reserved and how much that are not. This can be done if every campaign have a reserved amount attribute and a used amount attribute. When a user clicks on the campaign I withdraw money from the companies account and add them to the campaigns used account.
Related
I'm selling products inside my app, that unlock items on my server. Once the purchase is through, my server needs to distribute the incoming money of the purchase to different parties.
The account that I entered on iTunes connect is a EUR account, so everything will be converted to EUR (from what I've understood).
Is there a way for me to know the exact amount I'll receive into my bank account (from the receipt for example), so I can distribute the money correctly, or does Apple simply do a currency conversion at the time of the payment?
Apple does a currency conversion plus tax calculation depending on the country it was purchased in. You can see the exact exchange rate in your payout reports in App Store Connect. More information from Apple here:
Sales and Trends estimates the USD amount of sales and proceeds based
on a rolling average of the previous month's exchange rates. Final
payments in Payments and Financial Reports are based on the exchange
rate used to convert each report currency to the currency of your bank
account.
Usually, distributing money to users before you get paid from Apple is a risky business model that's open to exploitation. Users could refund their purchases and you'd have no way of knowing until it's too late.
A safer option could be to log the unlocked items and source country the purchase was from on your server, then divide up payouts from Apple when you get them based on these figures. That way, any scammers are distributed across the marketplace as a whole and doesn't come out of your pocket.
I have tow apps, the first one "hadeed" which is index for businesses, so each business have a channel (page) at "hadeed" app. this page describe the business details,show images ...
I have another app "hadeed manager" which used by the business owner , each user has a userName and password that sign with. with "hadeed manager" the business owner could change his business details(uploading images , change business location ...), then this updates will appear at "hadeed" app.
I want to charge the business owner when they updating details or uploading images using "hadeed manager". for example the user will pay 1 $ every month, then he can update his business details.
I've chose app purchase to charge business owners, the problem is that app purchase is associated with the apple id, so the bussines owner could login to business #1 and purchase the "hadeed manager" products, then log out from my system and log again to another business (in the same phone) and the storekit will show me that the user already purchase "hadeed manager" products.
How could I solve this problem ?
Sounds like in-app purchases aren't what you want, then, if you are concerned with an Apple ID holder having multiple businesses or accounts on your service.
If you are committed to in-app purchases, perhaps you should go the way of non-renewing subscriptions as in-app purchases. For example, why not offer a $1.99 in-app purchase that is "one month of service", and more price points for longer periods of time. These purchases can be made as many times as the user desires, and each purchased asset is associated with a business entity in your service.
Otherwise, you may want to put management, subscription, and payment on a simple web application for your business owner users -- what's to say that every business owner owns an iOS device? You'd get more coverage of businesses by leveraging a neutral technology for their experience.
On the getting started page for Apple Pay, it says that Apple Pay supports "partial shipments." How is this implemented in practice? I know how to get a token from a successful PKPayment. Once I get that token, how do I use it to implement multiple sub-order payments through my payment gateway?
For example, say the user validates a total $100 purchase through Apple Pay of two separate suborder shipments ($40 and $60 each) and I now have an associated token for the $100 order. Because of restrictions on some networks, we can't capture each payment until the associated item has been shipped, and they ship at different times.
Do I have the ability to authorize and capture payments of any amounts using that token?
What is the best approach to authorizing and capturing those sub orders?
Do I auth for the total ($100) and then auth for each sub total ($40, $60) at shipment and then capture for each sub total? If so, then I will be potentially authorizing more than the necessary total ($200), and that doesn't seem right. Is it valid to just skip auth for the total, auth for each sub total, and then capture the sub totals as they ship?
You can't capture an authorization more than once. For stripe you would need to save the token to a customer, and charge the customer for each shipment separately. This isn't only the best way it is the only way to do it.
Once you have a token and attach it to the customer object in stripe, you have the ability to charge it at any time & any amount up until the expiration date or if they remove the card from their apple pay account, like you would any other card regardless of the initial authorization.
The rest of your questions will vary by opinion as there are different ways of doing it, but here is how I would charge this type of order. I think this method benefits both the business and the customer, in addition to keeping stripe/apple happy. This isn't apple pay specific, I would treat most orders with these requirements the same. Also keep in mind apple pay supports it, but it is not required. You can collect all up front regardless of shipment dates.
Generate token from PKPayment for $100
Create customer(if needed) & add token to customer
Create charge against customer using that card for $100 without
capture
Within 7 days assess expected shipping dates.
Once assessment is complete immediately capture only the amount
expected to ship within a week on the initial charge. In your
example this is where I would capture $40 for the first charge. If
nothing is expected to be captured issue a complete refund.
Any shipments beyond the 7 days, create individual charges for the
shipments using the customer object, not the token. Again in your example this is when the $60 shipment goes
out charge that here.
As long as the second shipment charge doesn't happen to go out earlier than the 7 days this would prevent any authorizations overlapping resulting in holds of more than the initial amount at any given moment. I would treat almost any transaction like this apple pay or not.
I am developing online shopping App for iPhone. For financial transaction, I have used PayPal SDK and also created sandbox accounts for both buyer and receiver having US based account. I also had a test with US currency (USD) and credit/debit happens perfectly on both the accounts.
But, now I need to give support of non-USD currency, i.e INR as my App will be distributed over India. The only bottleneck is, INR is not in Paypal’s currency support list unfortunately. What should I do? Suppose, buyer buys product worth 100.00 INR and buyer have US based account having $ 500.00 balance. Now at end of transaction, based on exchange rate of these two currencies, amount should be deducted from buyer's account.
How can I manage this kind of multi-currency transaction ?
#Pratik It sounds like your app will need to do its own currency conversion from INR to USD, and then perform the PayPal transaction in USD.
There are many online currency converters, including some that return their results as JSON.
I know this is supposed to be simple but I'm having trouble coming up with a good, simple setup.
I'm building an app for a school. The school charges for things like pre-registration fee, supply fees, monthly enrollment, etc.
The most important aspect of billing is the monthly enrollment. Let's say it's $50 per month. I want to setup recurring billing (maybe with Stripe), but some people might choose to pay cash, or check or one-time credit card charge, instead of an automatic monthly withdrawal from their account.
Also, fees other than monthly enrollment, such as supply fees, books and such.
I was thinking about creating an Invoice setup, which I already have from another app (kinda like Freshbooks or Blinksale, [Item, LineItem, Tax, Invoice, Payment, etc]) but I thought that might be overkill.
So how would you set this up? Important points...
Ability to charge a monthly recurring fee and other one time charges
Able to track if item is due or if it has been paid
Track if monthly enrollment has been paid, MAKING A RELATIONSHIP between the payment and the monthly enrollment
I would just have a payments model. It would have a frequency (monthly, quarterly, half-yearly, yearly), payment status(paid or pending) and due date and type of fee(pre-registration, supply, etc)
If a guy opts one time payment in beginning, he would have all payments inserted and due date would be the current date and all the statuses would be paid.
If he opts for some fees to be paid monthly, he will have 12 records in payment table with frequency 'monthly'. The due date would be spaced one month apart each. The status of the last 11 records would be pending.
You can now track the list of payments whose due date is within next one month and take appropriate action.