Paymill's API is awesome. It's a blaze to work with, and I should be up&running, were it not for an edge case. Context is a SAAS app, with a demo trial, and the ability to upgrade & downgrade at will.
User cancels her subscription: at this point, her account remains active until the pre-payment date. Paymill receives 2 API calls:
DELETE call for https://api.paymill.com/v2/subscriptions/
DELETE call for https://api.paymill.com/v2/payments/
Scenario: She changes her mind, and tries to upgrade again. So far, I've tried modeling this via:
Doing a POST to https://api.paymill.com/v2/subscriptions with client, offer, and payment info -similar to the original subscription- returns Payment error: Subscription already connected
Doing a PUT to https://api.paymill.com/v2/subscriptions/ with payment info (according to Paymill API: How do I update a subscription's credit card? ) returns Payment error: the Subscription was canceled
Desired output is Continuing Subscription: no credit card charges are made until the next monthly period, and further CC charges are applied via the new payment info.
In what ways can this be achieved?
Many thanks!
Let me start by saying that the POST you described should be possible to execute. This is currently a bug, and this will be fixed sometime next week.
But your use case is, unfortunately, not supported at the moment. We are working hard to make our subscriptions feature more powerful, while retaining the simplicity of usage. We cannot offer a timeline for this, but we would love to hear more about your case.
Currently, merchants are encouraged to manage the subscriptions on their own, as this is not a simple matter of changing the amounts being charged on the next subscription's due date. For instance, if a client of yours decide to downgrade, would you make a pro-rata refund of the excess? Same for upgrade: would you charge the full amount of the new subscription on the due date, or a pro-rata of the old subscription + pro-rata of the new?
That said, I'd encourage you to keep an eye on our blog for announcements of an improved subscriptions handling.
Disclosure: I work at PAYMILL.
Related
I am looking to implement a referral program for our app that will gives users a free month off their subscription every time they have a successful referral.
I came across this question Stripe: add free days to a subscription but it is 6 years old so I am not sure if this is still the way to go since Stripe has updated their service and API multiple times since then.
Reading through the Stripe Docs it seems there may be 2 ways to implement:
Use a coupon and apply it against the customer's subscription. (Stripe Subscription Discounts)
Move the date for their billing cycle by 1 month (Stripe Subscription Billing Cycles)
I would imagine this is a common thing. Is there a best practice on how to proceed?
I ended up contacting Stripe customer support and option 1 is the way to go (coupons).
Basically you create a coupon that deducts 100% of the subscription fee and you enable it for 1 month only. This will effectively skip 1 month's payment. It can be enabled manually via the Stripe Dashboard or the API.
Follow this link for more details: Stripe Coupons
I'm building a platform, where users would be able to withdraw their earnings using one of supported services: PayPal, Transferwise, Bill.com and Payoneer.
I haven't worked with money withdrawal before, so I'm a bit confused on how it should work (npm packages, what would be the process in the context of the client-server comunication, best practices, patterns/antipatterns etc.).
My current tech stack is React + Koa.js
I would be appreciated for any useful information.
Thanks in advance.
I've built something similar recently, and here are the steps I've followed:
Collect beneficiary details from the user
This could be their Paypal email, bank account details or something else depending on the payment provider. If you go with Paypal or Payoneer, you'll need to ask the user to sign up for an account if they don't already have one.
Validate that the information is in the correct format
Especially if you are collecting bank account details, doing a bit of validation up front could save you a lot of hassle later on.
Saving the information securely
If you are collecting bank details, you need to decide whether you want to store the bank details in your own system, or if you prefer to only store them with the payment provider.
Storing the data in your own system allows you to review the information before passing it on to your payment provider. However you will need to make sure the information is managed securely.
Setting up the payment
You now need to decide how you will initiate the payment. You could let the user request to be paid. You could also do the payments automatically based on some rules. E.g. weekly payments if amount is over a threshold. Whichever way you go, most providers give you the option to use their API or some file based system.
Funding the payments
This will depend on your provider. Some allow you to fund the payments over API using a prefunded balance. Others require you to do final approval inside their system.
React component for collecting bank details
I needed to collect bank details that work with TransferWise for my own project, so I built <BankDeets/>, a React component that's available on NPM. It supports 40+ currencies and collects all the data you need to make payments.
Example:
<BankDeets submitURL="bankdeets.co/save"/>
It's available via npm install bankdeets (or https://github.com/321k/bankdeets) and comes with validation and translations. I'm the creator, so please ping me any questions about it.
Maybe this just isn't possible with the available Salesforce actions in Zapier, but I thought I'd ask.
You can monitor for a new opportunity, but I only want to create cards for opportunities which are closed won. So if a new opportunity is created on Monday and on Friday it is Closed Won, Zapier will never get notified when it is updated.
Seems like a very common use case, I figure someone has figured this out.
Thanks!
I took this to Zapier Support and they said....
So the tricky thing here is the "New Opportunity" trigger will only
happen when the Zap sees the record for the first time. Even if it's
updated later, the Zap will not re-trigger on it.
We do have a way to trigger on updated Salesforce records, but it
would require using their Workflow Rules and Outbound Messaging
option. Then on the Zapier side, you'd use the Salesforce "New
Outbound Message" trigger.
You basically set a workflow rule + outbound message in Salesforce.
And so all your triggering conditions (like which object/field) are on
the Salesforce side.
First you'd set up the Outbound Message, specifying the object and
fields you want to send, and the Zap url:
https://help.salesforce.com/HTViewHelpDoc?id=workflow_managing_outbound_messages.htm
Then you'd set up the Workflow Rule, specifying the conditions where
the rule should trigger, and which actions to trigger (the outbound
message action that you just made):
https://help.salesforce.com/htviewhelpdoc?id=customize_wf.htm
The one caveat here is that workflow rules are only available on some
editions of Salesforce. So you may have to check and see if your
edition supports it.
Please let me know if you have any questions about that -- happy to
help!
And that worked so yay Zapier for helping me with Salesforce!
What is the best practice to handle transaction between application and paypal.
Consider:
I'm Alice and I want send money to Bob
In my DB I see that Bob has $200 and I want to send him $150.
Once transaction is sent I want to update the Bob's account such that it would contain $50.
Now according to PayPal API I can send Pay and receive success. However what happens
if I for example send Pay it succeeds but I fail to receive a response due to network problem. So I assume that error happened and try again and technically I'll send $300 to Bob instead of $150?
How can I handle such a transaction - between a local database that keeps an account and the remote PayPal API?
I had this exact concern recently with an ASP.NET MVC project I was completing for a client.
I learned two things:
Communication between Paypal and your database cannot be trusted (well, didn't really learn this, but it was entirely reinforced)
I now understand why so many websites that have Paypal as a transaction type mention there could be a processing period between the time that the transaction was completed and shipping/delivery of the product is completed.
The way you handle the situation is similar to the way a business could handle personal checks:
A personal check looks like currency (and typically is), but many businesses would like some sort of verification from the bank that funds are available before they accept payment - so they use a machine that asks the bank if funds are actually available.
If the machine says the funds are available, the business trusts it and you complete the transaction. However, the machine can give an error message that typically means "the funds are not available or something went wrong" and the business has a decision to make:
We can trust the customer and accept the check, deliver the product, and hope for the best when later depositing the check to the bank.
Or we can tell the customer that it will take time for the check to clear, deposit the check, wait for the funds to actually arrive in our account, and (if successful) deliver the product after the business receives funding.
This sounds inefficient with the way many businesses operate today, but it is something that does come up. In fact, this is why a lot of businesses stray away from accepting personal checks, they are unreliable when compared to other methods of payment.
Now how does this correlate to handling a Paypal payment?
A Paypal payment looks like currency (and it typically is), but many businesses would like some sort of verification from the Paypal that funds are available before they accept payment - so they use Paypal PDT, IPN, or other method for checking that the transaction was handled appropriately.
If Paypal properly responds to one of the verification requests, the business can trust it and complete the transaction. However, your website may throw an error of some sort (i.e. Paypal could reply with an IPN response of NOTVALID, or you could never get a reply from Paypal). The business has a decision to make:
The business can trust the customer and accept that they have made a Paypal payment and everything should be alright (very bad decision in the case of a Paypal transaction)
Or the business can tell the customer at check-out time that there may be a 72 hour processing period for Paypal payments.
This may not sound like the best way to operate your business, but it is the way we have to deal with an imperfect internet.
I would set up the Paypal payment flow similar to this:
UserA wants to send $100 to another UserB using Paypal
UserA enters the value in the 'checkout field' and is sent over to Paypal to verify the transaction.
UserA is sent back to your website from Paypal and your website performs the IPN check with the details that Paypal has POSTed to your site(I chose IPN in this case - as if we were using Express Checkout as opposed to some other payment gateway that Paypal offers).
If the IPN is VALID, process the transaction as expected.
If the IPN is not VALID, mention to the customer that there may be a delay in processing, have your application send you a notification that a possible Paypal transaction issue has occurred (you may want to include a reference id so that you can quickly find which transaction this notification is referencing), and mark the transaction as pending as opposed to complete or something similar.
An admin of the site who handles these notifications will manually investigate the transaction (or force the website to check with Paypal again - see the Paypal API documentation for details on this) and manually mark the transaction as complete or failed.
Notify those involved of the status of the transaction.
It is annoying that we have to have extra steps involved to make sure the money was transferred, but, as mentioned earlier, we are using an imperfect system and we want to be very certain of the success / failure of financial transactions.
An added bonus to this process is that there is likely to be notifications when someone is tampering with the Paypal payment system - leaving you better equipped to deal with evil-doers in the future.
Please refer this link ,Hope PayPal Authorization & Capture method will be suitable for you ,since you don't want lose the response as well as miscalculated amount transfers, PayPal provides correlation id that can be referred for PayPal to confirm your order status,it will be better to pass the order id to PayPal API.
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_admin_authcapture
http://www.scribd.com/doc/6303345/40/CorrelationID-for-Reporting-Problems-to-PayPal
Good Luck!
This is known as 2-phase commit. As long as paypal does not participate in the same transaction, you will run into problems.
I would debit Alice the $150 and reflect the transaction is "Pending Confirmation", then periodically poll PayPal to synchronize your DB, since you have no control of when the network or PayPal may be available, post, reverse or adjust the transaction. Once PayPal processes the transaction, you can change the status in your DB from "Pending" to "Completed". BTW, this how bank accounts and credit cards are processed. You could apply a double-entry accounting method to your DB. (see this Q&A)
From what i see you need to make sure the transaction is complete otherwise nothing should be done .
If you deposit the money into PayPal API and you do not receive an response from PAYPAL API then you need to rollback the transaction in you DB.
I have a website and I would like to implement a paid subscription service. Its a simple service with only 2 types of plans. For now, ill just use Paypal. But im a little lost before start, mainly with the data model.
My main question for now is, what information do I need to keep for each subscription? Do I need to implement a shopping cart for this (dont think so)? Im not asking for a detailed explanation, just a few lights or resources to find a way to start. Thanks.
Depends on what technology you're using. Basic payments work a bit like this
-> You send them to paypal with a plan (you define the plan on paypal)
they know which amount to charge
you can pass custom parameters which they will pass back
Customer fills in application
<- paypal tells you that your predefined plan got purchased
in this same request, they send a lot of info about the payment including a GUID and your params
-> you ask paypal "hey, some one just told me this plan GUID got purchased, can you confirm"
<- paypal service returns 'yes'
-> you take the customer's ID from the params that you attached when you sent them to the paypal service and update them to "paid" in the database, or whatever
That's it in a nutshell...
Look at any subscription card mailer from any magazine and you can get an idea of what kind of data you will have to record. Start and end date for the subscription would be a good thing to keep, and what kind of plan the user is subscribed to. Once you have the end date, you just need to run a query to get the records of the users that have access. Something like
Select * from users where subscription_end_date is >= today
I'm sure there will be a lot of other columns that will go into your final product, but that will be up to you to decide what data you want to keep. What are the different states that a subscription can be in? Can someone be subscribed to both services at the same time?
PayPal does a decent job if you want to charge the same amount every month. However, if you anticipate your users making changes to their subscription plans (upgrades/downgrades) or needing to provide credits to their account for customer support purposes, PayPal would require that you cancel the subscription...and then have the customer re-subscribe.
[Full disclosure - I am a co-founder of Recurly.com]
Recurly handles the upgrades and downgrades, and provides automated customer emails to be sent out to your customers (on your behalf) for every event confirmation, and invoice that occurs. You also have a full account management dashboard and reporting so that you don't need to build this yourself.
Best of all, if you ever decide to leave PayPal, and move your business to a standalone payment gateway, Recurly stores all of your credit cards in a PCI compliant vault so you don't need to ask you customers to come back and re-subscribe. (PayPal will not return your customer credit card information). You simply configure your new gateway in Recurly, and payments will be processed without any interruption to your business.
Here is a blog post we wrote on the topic:
http://blog.recurly.com/2010/08/top-ten-reasons-to-use-recurly-vs-paypal-for-recurring-billing/
-Best of luck.
-Dan