I have a client that has a shopping cart. She wants to implement a module that allows the end user to receive a tracking number immediately after purchase.
I am not too sure if this is possible. My concept is that after the store owner ships the purchase, that's when the store owner receives a tracking number that he/she can give to the purchaser. And the purchaser then can start tracking their package.
I guess my question is... "Is it possible to generate a tracking number to give to the purchaser before the store owner even bothers to wrap up the order and send it out.This is so the purchaser can automatically start tracking their purchase and the store owner doesn't have to manually give them a tracking number." ?
I know this would have to require the api. I just need to know if this is possible before I start investing alot of time in trying to build it.
She is using Magento for her shopping cart service.
You can use what's called a tracking reference.
From UPS:
When you create a shipment, you can
assign a shipment reference that helps
you track quickly and with ease. This
reference can contain up to 35
characters in any combination of
letters and numbers
http://www.ups.com/content/us/en/resources/track/check/#Track+by+Reference
UPS will store this reference number in its system so that you can have customers track with that instead. They will need to click Track By Reference in the Track Packages & Freight tab.
It's "possible" in that way that everything in software is possible. There's nothing built-in or third party that I know of that would build this functionality into a system though. My experience with the UPS shipping API says that even if you created a UPS shipment at the time of ordering, there's a non-deterministic delay before the actual shipping code is created. See mention of tracking reference in this thread.
If you want to move forward with this, it means creating your own tracking system. Immediately after generating an order you also generate a unique tracking number, and a tracking URL. This URL points at your system, and returns a page that lists ou;t any UPS, FedEX, etc tracking numbers that are in the system for that order. If the order hasn't received its number yet, you list a message like "at source warehouse" instead.
Good luck, ERP and fulfillment integration is always a bear.
As far as i think Magento has built-in support for such tracking services.
Dont remember if it supports UPS but i guess it does.
Otherwise use the UPS Developer API and play around with their web services.
And for the advance tracking number as you require that feature is also implemented in Magento for shipping packages as well as order tracking etc...
PS: I observed these in Magento 1.4+
You can get bundles of shipping forms with fields such as your business name, address, account etc that are prefilled. These bundles also have sequenced tracking numbers.
You would have to get these bundles and upon receiving them enter the starting number and ending number of the stack into a database. From there the person packing the order must be careful to use the correct form with the order.
If you interface with ShipWorks and set it up with your UPS account, it both creates your UPS shipping label, gets the shipping charge and posts the UPS tracking number back to Magento. Very smooth integration.
Related
I am currently planning a new website for a local car hire company. They want a form where a user can input their personal details, select the car they want to hire and when they want to hire it etc. They do not want to take any form of payment on the website, but still insist on taking the user's credit/debit card details that they will then process on their card terminal at the time of hire when the customer picks up the car.
I have looked into a few options about how to achieve this, but keep stumbling on the card details gathering point. One option I have looked at is using WooCommerce (I am building on WordPress) along with this plugin https://www.wplab.com/plugins/offline-credit-card-processing-woocommerce/.
I am looking for any suggestions on a suitable and secure way of gathering the card details with this reservation form, with or without the use of WooCommerce.
Do everything you can to avoid taking credit card details, especially in the case where you're not actually performing any charges against them. Otherwise, you open yourself up to a whole new world of pain, the least of which is ensuring that your whole system design is PCI compliant.
I would try to find out why they think they need the card number ahead of time. When the customer gets to the physical location, the business will get a lower rate from the payment processor if they perform a card present transaction, which means it's actually cheaper for them to not collect the number ahead of time. That alone should be enough of an argument to sway them. If they insist on still taking the card numbers offline, hit them with a huge quote to make your system PCI complaint. It is no joke.
Use a secure SSL connection for a start!
Try a Credit Card validator such as https://framework.zend.com/manual/2.4/en/modules/zend.validator.credit-card.html
I have a website coded in PHP that uses paypal buttons/IPN for subscriptions.
The method is limited and I need to replace it with the REST-API.
What the system needs to do:
Accept new user recurring-payment subscriptions
Be able to change plan pricing for new users
Be able to change plan pricing for existing users
Change subscription plans mid-subscription(If a user upgrades from pro to master the price goes up, and the opposite way it goes down).
The price difference between packages is 5$
Give periodic discounts for a limited amount of months.
The questions:
1.) What is the equivalent of recurring-payments in the PHP-API or REST-API? (I'd rather it auto-charges and notifies my IPN if possible)
2.) How can I automatically refund/charge an additional amount when the user upgrades/downgrades in the middle of a month?
3.) Is there a standalone PHP control-panel that can connect to the paypal API to manage the subscription packages + sales?
Thanks in advance!
If you are looking to use REST APIs, the best place to start is going to be at the REST API docs. For your situation, you can use the vault to set up a recurring payment system. You could also use the future payments API, but you will need to make sure you buy DPRP for your account. Contact PayPal Customer Support to enable DPRP.
With the Vault API, you can just create one time payments over and over with the token you get when storing a credit card.
There is an in-depth walkthrough using the SDK on the PayPal PHP SDK Wiki.
To do refunds, you can use the Refund REST API. All this assuming that you would be writing scripts to detect your user downgrading/upgrading. You would just need to store the amount they are paying each month in your DB.
There are some shopping carts out there that are implementing REST APIs. You might need to google search for something like that.
Hope that helps and gets you started in the right direction!
I have started working on a e-commerce website. This website will run PHP and MySQL and requires to have a credit system for the users; they will be able to pay with the credit, top it up by vouchers or regular payment, as well as withdraw.
Now I do have experience with credit cards processing APIs, so paying money in and out shouldn't be a problem; what however is a problem is how to securely store the credit information. Storing it as a single numeric field is not exactly ideal and potentially could be exposed fairly easily. What I was thinking is keep all the transactions and credit history of each user in a separate table, and every time they log in recalculate what should their credit be. Same would then apply before any transaction that they attempt to do.
I would like to hear what are your thoughts how this should be implemented.
EDIT: Just to clarify; my question is not on how to process credit cards and won't be storing credit card information. I will use a well known and secure API to process the payments (e.g. via paypal). However based on the credit card payments, I need to attribute the appropriate user points in a form of credit. These points would be a representation of funds on the website (whilst the money would be retained on the company account, until the user tried to make a payment/withdrawl) and would be used to make payments and withdraw funds. Again for the actual payment processing I would use secure API, however I am not sure how to implement the credit points properly from structural point of view in the application itself. I don't want to use a simple one field point system, as that I would consider very dangerous.
I hope that clears it up a bit.
Cheers
This might not be the answer you are looking for but here are my 2 cents.
In my personal opinion unless you have someone monitoring your dedicated servers 24/7 you should never in any format store credit card numbers in your database, it is just too risky.
A very nice solution I came across last year was BrainTree http://www.braintreepayments.com/. You can set up a very nice credit card payment system without taking on any liability yourself. Their API allows server to server and transparent redirect (form posts to their site and they redirect back to your site) transactions. At the same time their Vault service allows you to store credit cards on their end and you just use a token in the server to server API to process a payment. You can store the last 4 digits (which they provide in the transaction detail) in your DB along with the CC type and the token, with this you can display a drop down for the user to select which card they want to use and you just use the token when talking to their API.
The API is very nicely documented with full examples. I think you should look into them.
Edit:
I believe you should have a table as you have suggested to store all the history and 'totals' field in the users table, which can be used to display in various places. Each time a transaction a made calculate the total and cache it in this field for ready usage. However it is a good idea to re-calculate this in certain crucial places to make sure everything is in order. Even though this field is exposed but you have a full log which can help you re-calculate everything if needed.
I'm working on a project that ties into an API and uses virtuemart. Basically a user can buy time for a phone card. the few things I need help with are:
A) can/how can I create a custom php function once the user signs up. For instance, the user adds Items to the cart and proceeds to checkout. once the user clicks checkout they need to create an account, after they create an account is there an area in this process that allows for a custom function so that I can tie the creation of the account to an API?
B) same as above but after checkout. After the checkout goes through, how can I make it so the new values are sent to the API? Is there an area in the files that allow for custom functions here.
C) Lastly is it possible to add more options the the virtuemart customer account maintnance screen. I want an option that will tie into the API and show them exactly how much time the have left for their phone card. This information will be provided by the api.
All of these things can be achieved with a System Plugin. You would simply look for the right url, get any information from the result screen with regex, call your API and insert any changes back into the screen.
I'm not specifically aware of any VM functions for this, but as VM is in flux with Version 2 getting closer, it may not be a good time for any such investment in any case.
I have been looking at setting up web applications that rely heavily on the ability for users to frequently and substantially modify subscriptions. I may be using marketplace features as well, and I need a system that supports both seamlessly.
I have seen multiple horror stories about the complexity of modifying subscriptions, including double billing, or cutting users off at the wrong time.
I sincerely hope, for instance, that this article http://talklikeaduck.denhaven2.com/2007/09/02/how-to-cure-the-paypal-subscription-blues
is out of date. The use cases that I have in mind are even more complex than the ones that he mentioned. For a sampling of what I would like to do:
Support multiple subscriptions and
subscription types/levels. For
instance one user might have 1 Plan A
billed monthly at $10 and 10 plan C
billed at $50 per month and 1 Plan D
billed at $100 per year.
Support changing of arbitrary payment amounts. For instance, user was on the $40 per month plan, but then changes that to a $100 per month plan. Then cancels, then signs up again at $50 per month before the $100 period was up. The user should still get $100 of service for the month that he paid $100 for, and then should change to the $40 per month plan.
Allow for payments of subscription amounts between my users. So one user might initiate a payment of 50% of whatever amount he has paid into the system so far. My application will be handling these types of marketplace style operations and these payments should work in the context of subscriptions...
It does not appear that there is an Open Source PHP library that does what I need either with Amazon or Paypal. So I am looking forward to coding this myself. (be glad to be proved wrong here, perhaps a Freemium for PHP?). I cannot use the various subscription services that are available. Because they generally do not support the features above, and because I need to have direct access to the PayPal or Amazon FPS API for later cleverness via marketplace issues.
Which brings me to my question. Which payment platform should I choose for ease of managing subscriptions? Please send me in the right direction, I only have so much time. But I also do not have time to make the wrong decision. Please provide evidence for your preferences, and if possible detail your work comparing the two systems. Google has the only other payment platform and currently their subscription system is in beta.. If you propose some other better system, please provider tons of good reasons, because I need a popular payment engine that people will feel comfortable with!
-FT
I see you asked this question back in December... if you haven't found an answer yet, I have some suggestions based on my experience with a business problem almost identical to yours.
Which PayPal API are you thinking of using? In using the PayFlow XML API, I found it was thousands of times easier to just roll my own subscription service. If the API you're using supports creating 'reference transactions' based on the previous successful transaction ID, you may save yourself a headache by keeping track of users' subscription amounts, keeping track of what's been paid, and creating a billing script that runs on a daily cronjob, checking each user to see if they need to pay (and how much), and then creating a reference sale for each of them.
Of course, don't forget that you have to explicitly ask for users' permission before you start billing them on a recurring basis, and there should be a good recurring billing and privacy policy. One trouble with this setup is that you pretty much need to create your own scripts to manage people's subscriptions and payments -- fortunately, I was tacking PayPal recurring billing onto a web app that already had subscriptions and accounting built-in.
Let me know if you need any suggestions on how to go about this!