I need to send an email notification to customer after the order is delivered to the customer. Is that thing can be done by default magento, or I have to purchase any module for that. Please help.
This is basically depends on you delivery partner. If they can inform you about the order delivery at real time, you can do that. Run a cron job every 15 mins, to pull every delivered order Or check statuses of order which has "processing" or "complete" status in backend. By that you can knowing delivered order, send a notification to customer.
Related
I am creating a payment system for a small SaaS Startup. We want to provide a trial period for our service, when a user subscribes using the Paypall subscription. To be complient with the law, we have to send an invoice, stating the length of the trial period. The invoice should state, that it has already been paid.
I recently subscribed to Overleaf and the invoice, that they send seems perfect for my goal, so I attach an image as an example.
The problem I have with paypal is that it has separate payment options for subscription and invoices.
In the RESP API docs https://developer.paypal.com/docs/api/subscriptions/v1/ there is no information about invoicing after the user has subscribed even though this is a very common scenario for the subscription event flow. Thanks in advance for any suggestions on how to implement it.
I'm using PayPal to take subscription payments for access to a website service.
I'm using PayPal's IPN to manage the payments and user accounts.
I'm sending a custom random key to PayPal, unique to each user, when the subscription is first instantiated so the same key is sent back with every IPN. This means I can bind together my users table with my PayPal notifications very positively.
Accordingly I can now generate from my database a list of user_ids and notification details.
So now I need to figure out the best logic to use to calculate each users current payment status and, as a consequence, what to do with their account - whether to continue allowing access, suspend or even delete their user account. This decision will all come down to whether their payments are still coming through or not.
A bunch of interesting an varied data comes through on PayPal's IPN - most looks irrelevant in terms of user account management but a couple of columns look quite useful. Specifically...
Field outstanding_balance appears to contain exactly that - a value to 2dp of money still owing. So far during my testing this figure has only ever been 0.00
Field txn_type shows me any from a selection of different codes: subscr_signup (when the user initially sets up the subscription), subscr_payment (when a payment appears to be successful), subscr_cancel (this seems to appear whether the customer or vendor cancels the subscription), and subscr_eot (end of term - this one crops up shortly after the subscription is cancelled).
My impulse is to search the table for the most recent txn_type="subscr_payment" entry for each user account, and check the date this last notification arrived. If it is date stamped over, say, 28 days ago the account can be suspended... if it's over 56 days the account can be deleted.
Is this a good idea? Or is there better logic I can employ?
I've done this. Quite simple:
Don't grant access until you receive the first payment. You can get the intial signup and payment in either order.
PayPal will notify you if they cancel their subscription or it expires. When you get either of those, deny access as from the effective date.
If the most recent payment status on an account is 'reverse', suspend access until you either get 'cancel reverse' or the situation is sorted out in some other way.
Don't count the days. PayPal counts the days. All you can get from repeating that yourself is a disagreement, and guess who's right? PayPal. And guess who isn't wrong? The customer. You don't want to penalise the customer because PayPal got behind or had a different idea of 28 days from yours. You've handed responsibility for collections and renewals to PayPal: let them do it.
Beware of building policy into this. It should just be a mechanism, and it should be manually overridable. For example, the actual evaluation of whether this user has access to this product now mustn't be a computation over their payment history. Just a simple lookup of another table, which your IPN code can modify, but so can humans. For example: there is a dispute. You lost. You might well as a matter of business want to keep the customer alive for a grace period anyway. Alternatively you might in extremis want to fire the customer immediately, e.g. for usage violations.
You can ignore the balance field. The only important thing is the txn_type.
Is there a way or an extension out there that allows a Magento order to get a different status automatically once a payment has been captured?
The reason why we're looking for this is because we connect to ShipStation (www.shipstation.com) for shipping and eCC Webgility (www.webgility.com) to post orders to our accounting software. We need a more automated way for those orders that get pulled in for us to know whether the order has had funds captured or not. The only way for us to do this now is manually change the order status since Magento's default method keeps the order in "processing" regardless of it being invoiced or not.
You'll be able to do all of that with an Instant Payment Notification (IPN) solution.
For any transaction that ever hits your PayPal account, whether it's a payment, a refund, a cleared or failed pending payment, disputes, etc. their server will POST the transaction data to a listener script on your server.
Within this script you can use that data to update your database, generate custom email notifications, hit 3rd party web service API's, etc. all automatically, in real-time.
Is it possible to register some PayPal web hook that will get executed whenever some transaction with concrete seller changes it's status, becomes charged back etc.? I couldn't find anything about this in docs. It would be much efficient than periodically checking status of every transaction.
Thanks!
Check out Instant Payment Notification (IPN).
Instant Payment Notification (IPN) is a message service that notifies
you of events related to PayPal transactions. You can use this service
to automate back-office and administrative functions, including
fulfilling orders, tracking customers, and providing status and other
information related to transactions.
Note: you can register ONE place to be notified ... and it will need to parse out which notifications should be handled by what code.
https://www.paypal.com/ca/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside
Paypal has 6 different txn_types. I assume on "subscr_signup", I have the first payment in my hand and I can send their license. Then lets say halfway through the subscription they cancel, I will get the "subscr_cancel" notification? Then at the end of their paid period, I get the "subscr_eot" notification. Is this correct?
Therefor, in a recurring billing system, I just need to create a license on "subscr_signup" and delete a license on "subscr_eot"? Is there anything I'm missing? I just don't want to rip the buyer off.
Thanks!
I assume on "subscr_signup", I have the first payment in my hand and I can send their license.
No. You can get subscr_signup and subscr_payment in either order. You shouldn't send anything until you have the money. If doing that requires what's in the signup transaction, that means you need both transactions before you can do anything. In my system I create the user on signup, but I only give him his permissions and send him an email only if both transactions have occurred.
Then lets say halfway through the subscription they cancel, I will get the "subscr_cancel" notification?
Correct.
Then at the end of their paid period, I get the "subscr_eot" notification. Is this correct?
Yes. You don't need to do anything particular about subscr_cancel. All I do is send him an email asking if there is anything we can do to retrieve the situation.
Therefore, in a recurring billing system, I just need to create a license on "subscr_signup" and delete a license on "subscr_eot"?
Not quite, see above.
Is there anything I'm missing? I just don't want to rip the buyer off.
You need to handle subscr_modify. I handle it by terminating the current subscription as for subscr_eot using the effective date supplied as the end date, and starting a new one as for subscr_signup` using the effective date as the new start date.
When you check for payments, e.g. on subcr_signup, you also need to look out for payment failures, reversals, etc, to make sure you've really received the money. You have to to check the payment_status. I also have some logic somewhere to make sure the last transaction on the account isn't a reversal.