Paymill:
I'm developing a website which sells subscriptions. Whenever a new customer signs up I do the following:
Create a new "client" at Paymill
Create a new "payment" (the customers credit card) at Paymill
Add a new subscription at Paymill for this "client" using this "payment"
There are no trial periods, so Paymill issues the first transaction immediately.
But sometimes the first transaction fails, I can see in the cockpit this is due to any of these errors: https://www.paymill.com/pt-pt/documentation-3/reference/api-reference/#document-statuscodes
But how can I know this? There are no response codes in the returning subscription object (the subscription is set up fine, but the first payment fails).
What have I missed?
there are no responsecodes for subscriptions you are right, but you should register webhooks for this. Than you'll be informed if a transaction of this subscription fails and also gets the errorcode. Please have a look for webhooks here https://www.paymill.com/en-gb/documentation-3/reference/api-reference/#webhooks.
We will also make a refactoring for subscription in the first quarter of 2014. Than we'll improve also the responses.
Best,
Christian
Related
We have an existing saas app where we used to handle payments for subscriptions offline in a manual way. (They pay us directly to our accounts and we update their subscription data in our database manually).
Now we are moving over to stripe so that customers can automatically add/renew their subscriptions on our platform (via stripe).
Since our app queries stripe to fetch the customers current subscription, we will have to somehow move all old subscriptions to stripe but I am not sure how to proceed with that.
What I expect at the end:
Add a subscription for all old customers to stripe WITHOUT charging the customers anything (as they have already paid to us outside of stripe).
Then when the subscription ends, let stripe proceed with its flow of auto-charging the customer.
I don't really care if the interval of the new subscription in stripe is from today to today+365days even though the customer purchased our services 3 months back (we don't mind giving him an extra 3 months for free)
What i tried and didn't work:
Create a subscription manually for the customer (via the api/dashboard) but stripe throws an error saying no payment method set for the customer which leads me to believe that stripe will want to charge for this subscription.
Approaches that I am evaluating:
Create a coupon with a 100% discount while creating a subscription for the old customers. But I am not really sure if this is the right way to approach this (what happens to stripe fees here?)
I would really appreciate it if someone can shed some light on what approach to take here?
Thanks!
I believe you can create a Subscription with a trial period. Ie. If your customer purchased your services 3 months back, you can create a Subscription with trial period = 9 months, or even 1 year if you don't mind giving them 3 months free until today + 365 days.
When a subscription is created with a trial period, it won't ask for a Payment Method. When its billing cycle is approaching, Stripe will send a trial_will_end webhook event for you to start collecting your customer payment method.
There is also a Stripe's official doc for trial Subscription.
I have created shopify app and setting up billing Api. In the App, I want to apply trial period of 20 days. I have created the charge during the app installation and send customers to confirmation url so that they can accept or decline the charge.. So I want to know that if customer decline the payment charge, then can he uses the app featurs till trial period?
If a customer declines the subscription, you still get the confirmation URL callback. Examine the charge. The status will say declined. At this point you can kill off their DB token and destroy their session. This will ensure they cannot use your App as they declined the terms.
It is one bad aspect of the whole billing scenario. I have lots of customers that are faced with a question they don't read. So they assume the trial you offer for free is activated by declining the subscription. Silly customers... still cannot operate the Internet :)
I need suggestion for paypal pro API which allow me to pass variable amount each month. For some months,it can be zero too.
I tried with UpdateRecurringPaymentsProfile but it gives me error of 11592 (Subscription profiles are not supported for recurring payments).
Please someone help me with easiest solution.
Based on the error you mentioned it sounds like you're using a PayPal Standard Subscription button, not Pro. If that's the case, then as the error says, you cannot update standard subscriptions with the APIs. You would have to use the recurring payments API to create the profile in order to then update it.
That said, you won't be able to do variable amounts with recurring payments profiles. you can only raise them by 10% every 120 days, so that typically doesn't work with what you're trying to do.
Instead, you'll need to use reference transactions. So if you're using Payments Pro that will be real simple. You just pass in the transaction ID of an original authorization or sale transaction along with a new amount you need to charge. PayPal uses the card details on file to process the new amount.
If you're using DoDirectPayment then you'll use DoReferenceTransaction for the future payments. If you're using PayFlow you would use the PayFlow API, of course, and change the parameters to match a reference transaction request.
You can also do the same thing with PayPal Express Checkout, but in that case you'll need to include billing agreement parameters in the SetExpressCheckout request, and then you'd use the billing agreement ID you get back from that in the DoReferenceTransaction request.
In any case you'll need to build your own script to run everyday, pull profiles that need to be charged, and charge them accordingly.
Customers have started to find that the transaction description field provided by Yodlee is changing, without the original / older transaction being removed and a new one being created in it's place.
Our expectation up to now is that if any changes take place, the old transaction is deleted and a new one is created, with a new internal transaction_id used by Yodlee. This is the system that is used for moving pending transactions to posted.
Is it now standard practice that merchant descriptions change frequently within the same transaction ID, or is this being done in error? Should we open a service request for the problem to be resolved?
Yodlee scrapes transactions from the Bank websites in each refresh for a specific duration- 30days, so if there are few transactions which got scraped and filed into Yodlee DB in previous refresh and now Bank has updated the description of those transaction while keeping rest of the information same. And say those are coming in current refresh also, then Yodlee will apply its logic and will update the description without changing anything else. But the chances when Bank Website does this is very rare.
If you are facing this kind of issue repeatedly/frequently then we suggest you to open a service request, with all the relevant information.
Note: The above scenario is in the case of Posted Transactions only.
We're setting up a system that will use the XML API for Automated Recurring Billing with Authorize.net.
It looks simple enough to set up a recurring billing. But we have two features that do not seem obvious
* providing customers with details on individual payments
* providing notification to customers of expired/canceled cards
Anyone familiar with a mechanism to retrieve this info in automated form? We're considering
* just listing out assumed payments based on our own calculations the start date
* emailing customers based on the expiration date of the ards
But I'm stymed on how to figure out when a transaction failed due to canceled card (and automatically notify the customer).
Can anyone comment on how they handled this issue when implementing a subscription-based service based on Authorize.net?
Authorize.Net has recently published a new ARB method "ARBGetSubscriptionStatus".
You may now easily query the status of a previously submitted ARB subscription without the need to depend on the "Silent Post Method".
Example:
<?xml version="1.0" encoding="utf-8"?> <ARBGetSubscriptionStatusRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication> <name>mytestacct</name> <transactionKey>112223344</transactionKey> </merchantAuthentication> <refId>Sample</refId> <subscriptionId>100748</subscriptionId> </ARBGetSubscriptionStatusRequest>
You want to use Authorize.Net's silent post feature. It will notify you of all payments made through their system including declines and expired credit cards. Your script will then be able to suspend accounts and/or notify your customers that their payments has failed.
See these link for more info:
Handling Authorize.Net ARB Subscription Failures
All About Authorize.Net’s Silent Post
Handling Authorize.Net Silent Post with PHP
You need to use the Silent POST URL
ARBGetSubscriptionStatusRequest will not work. If the first transaction (or first transaction since the ARB profile was updated, either via API or manually) fails, the status of the subscription is set to suspended. Otherwise, the status of a subscription does not change when a transaction declines or a card expires.
Using the Silent POST URL, you'll be notified of successful transactions and you can use them to update your data such as tracking a next payment due date/expiration date. You can then run a cron job and if this field has not been updated, you will know that the card was cancelled or expired.
In the event that it is still an active card but gets declined, you'll get notified as such at the Silent POST URL