I have a subscription business model (SaaS) that I integrated with Paypal via API. I have a monthly plan and a yearly plan, both of which provide access to my SaaS while the subscription is active.
Now, I would like to give discounts to my customers : months of free subscriptions and lower fixed price for a limited time, not a the start of the subscription, but later, depending on actions in my SaaS, and without asking the customer to confirm the action.
I tried many things, but couldn't give a free month without suspending or revising the subscription. As the discount is favorable to my customers, and could happend without actions on their side, I don't want to ask them for action to get the discount or notice them that their paypal subscription is suspended that could make confusion because they keep the service, they just get it freely for X months.
I succeed to reduce the fixed price of a subscription, but never for the value of 0€, and not temporarily.
Idealy, I would like to change the plan of my customer to a plan with X months of free trial (which I could increase) before returning to the normal price; or give them X€ "coupons" automaticaly applied once a month but the PayPal API doesn't seem to offer ways to do that.
Does someone have any workaround to deal with this ?
Related
I am creating an application that users could deposit money on their account and trasfer to other users. I am wondering if Markle Tree is the ideal solution for SQL transaction for money transfer. I've read this article, and came with the idea of implementing this kind of "security" in my app for preventing someone to change some values.
So, how could be the best solution to implement on my database model, does anyone could help me? For now, my database look like this:
The main idea is to create a transaction since there is a payment, and the transaction only occour if the sum of the value of all transactions of the user is equal to the amount in his account. Is that a good way, or could be better?
I don't really understand what you want to achieve. I understand that you want to sell something on the internet and you are creating a database for it. If you want to sell a subscription, the more important issue is the validity of the purchased service (date from-to). Take a look at the model below.
Database model for transaction-subscription:
I have a durable product. It purchasing correct and handling with CurrentApp.LicenseInformation.ProductLicenses too. But after application update system "loses" information about purchases.
I may call CurrentApp.RequestProductPurchaseAsync() again and user will just accept the message that the product was bought. But this is quite inconvenience. Is there a way to restore in-app purchases after update (beside saving this information into settings)?
I'm trying to create a payment system for my website. The website is a market place for 3d printing blueprint. Users buy credits on my website. When a user purchase a 3d printing blueprint uploaded by other user, it creates a new tuple or a row in the 'purchased' table while deducting credit in user credit table. Here's the important part. My gut tells me to use event scheduler to mark rows of purchased as payed every month and wire the sum of money earned by each seller. My worry is the table will grow infinitely as months pass by.
Is this the right implementation?
Or can I somehow create a new table each month that holds transactions for only this month?
Is there a Nosql equivalent to this?
Stripe.com or Braintree.com might be good options for you.
It is not advisable to create or roll your own payments implementation. These established services not only handle the PCI compliance aspect of payments, but they also have direct support for the use case you're asking about.
In an effort to answer your question further - it's probably not going to be an issue from the stand point of performing inserts into this MySQL table or in terms of iterating across it for batch processing. Querying on the other hand will become more onerous as the data set gets very large.
You can use partitioning in MySQL and perform the partitioning based on date but I doubt this is something you should spend your time accomplishing at this point. Wait until your site blows up and is super popular then come back and update your schema and configuration to meet your actual usage demands.
It's worth noting that you'll also want to make sure to take regular backups of something as important of payments information. Typically you'd also see at least one replica for something this critical.
Again I don't think you should try and solve this yourself. Just pay for a service that does this for you and focus on building the best 3d blueprint marketplace.
I have a problem related to automatic task scheduling.
Currently i am able to find out when my customer has last credited his account, how am i able to find out whether he will pay anything in the next 3 days?
So if no payment has been made in the next three days for any customer, to automatically alert me preferably by a notification directly to my ipad.
I dont want myself to open the app for checks to be done only when i log in, because then if i jump on my application 6 days later, i could have had a customer that hasnt paid in 6 days when the app should have alerted me on the 3rd day so i could ring my customer up to deal with the matter.
I need to work in this matter due to the structure of my application and business.
I am able to monitor everything else but need some insight on how I can go about doing this. the current notification system inside the phone only fires based on time, and I cannot do interval checks where maybe i could run a background task, if that would work then i would have done it like that but thats not the case.
Pavan
If I understand your question correctly, you should compute the interval of the event that you want and post a wake-up timer that is that period of time from "now." If you need it through the notification center, then just handle it silently and clear it from the notifications.
Based on the discussion below:
You will need a little bit of server work. APNS looks complicated, but it really has very few moving parts -- especially if it is a private App. What system component is keeping an eye on Amazon? Do you have an App or web server? For example, if I were to poke a record into your system (purchased services) what workflow is triggered to notify Accounting to process an invoice and collections at a later date? Am I making any sense of your system architecture?
Perfect - you are done. You have all the system components you need and the rest is coding. The server app processes the accounts DB and finds new entries. If found, it publishes a record ID to the APNS server (Apple owns this server). You write code to register to receive the push-notification (subscriber). When you get a push, that will wake up your registered app with the record ID (and some other subscription stuff for bookkeeping -- but you are the only subscriber and only subscribing to one DB table -- so you can largely ignore. Now turn around and query based on that record. Done!
First of all, sorry for the question title - I was unable to think about something better.
I have an interesting problem.
There are three web applications:
1. ApplicationA => example.com -> hosted in Germany
2. ApplicationB => example2.net -> hosted in Australia
3. ApplicationC => anotherexample.com -> hosted in United States
All of them are completely free however owner is planning to implement some paid options. The main issue is that applications are hosted on separate servers, in three different locations.
Now, if owner wants to implement any paid options, he needs to created unified invoicing system (as invoices numbering order needs to be correct).
So, we have situation:
1. user buys a premium option on example.com
2. another user buys a premium option on example2.net
3. third and fourth users buy extra options on anotherexample.com
So we have 4 invoices, so they numbering should be as following: 2011/01, 2011/02, 2011/03, 2001/04.
As mentioned above, the main issue is to unify invoicing system as applications use different databases and are hosted on different servers. Of course, invoices should be stored in application-specified database.
Theoretically we have only one issue: invoices numbers. Obviously we need to create a unified system for invoices storage.
There might be few possible issues:
there might be a lot of API requests to invoicing system
every single invoice needs to be stored in the database
while creating every single invoice in every external application, we need
to query invoicing system for the
latest invoice number.
I'm really interested in your knowing your approaches and suggestions. Any activity in this case is highly appreciated.
First, I would have the independent invoicing systems in example.com, example2.net and anotherexample.com all have their own internal primary keys for the invoices generated from within each of these systems. Each system should have its own independent copy of the invoicing logic because you don't want an outage on one server knocking out invoicing on every server.
Whenever you have a distributed system where local copies are creating records for something that will be amalgamated later, it's a good idea to use a GUID as the local primary key, or if you have a philosophical objection to GUID as PKs, create a GUID as a candidate key. This way, you can bring together invoices from all of your systems (and any future ones) without worrying about key collisions and you'll be able to track the combined records back to the source records, should you ever have to do that.
Next, you'll need an integrated invoice system where all of the invoice details are collected periodically. To facilitate this, you need processes on each local invoicing system pumping their own records up to the centralized system. Keep a flag on the invoices in the local systems to identify which invoices have been successfully uploaded - or if you have very high volumes, use a work-list table containing the invoice keys that still need transmitting instead of a flag right on the local invoice table.
The centralized invoice system will also want to have a source code on the combined invoice table so that you can easily tell which website created the invoice originally.
As to invoice numbers, I'm assuming from your question that the customer is a bit fussy about having proper sequencing of your invoice numbers. You can have the centralized system generate these numbers for you using a web service to pick up the next invoice ID. If the centralized service is down for any reason, you can still give the customer an "order reference" i.e. the GUID and just hold back on the invoice number until it can be generated through the central server. This should satisfy your customer's need for tight sequential invoice numbers while preserving the ability to operate multiple sites on multiple servers.
If your customer actually doesn't care about tight sequencing of the invoice numbers, then another alternative is to have the central system generate blocks of reserved invoice numbers and allot them to each website. When the website is getting low on its allotment, it asks the central server for another block. This gives you breathing room in the sequences in case there are communication difficulties.
In my opinion, it would be better to use an encoded invoice number. This way, you won't need to worry about number order getting mixed up.
For example, invoices can be prefixed with the country domain like de297,de298, etc., for invoices from Germany.
And going one step further, I'd incorporate the year as well. Thus it would reset at the beginning of each year and still maintain no conflicts, while at the same time keep the invoice number within a small length.