I need to know if this is possible with PHP, or possible at all...
Let's say there's a shopping cart done in PHP. payment processing is via PayPal.
Customer John adds 2 items to the value of $70 into the cart. Now, John pays only 20 bucks. Then Peter and Jim volunteer to pay the balance. Peter pays $30 one week later using his MasterCard. Jim pays the remaining $20 after another 10 weeks. This means that the PHP code needs to keep track of the PayPal payments to the SAME transaction.
The key question is: DOES PAYPAL OR ANY OTHER GATEWAY ALLOW SUCH MULTIPLE PAYMENTS TO THE SAME BILL BY DIFFERENT PEOPLE OVER A PERIOD OF TIME?
Even a link to the PayPal system's documentation that shows this would be good for an answer. But it MUST be able to satisfy the rules above.
Thanks!
You would have to modify an existing shopping card, or create your own to support this. Allowing different people to pay for the same item is easy enough with SQL, just be sure to keep track of the payment_status updates for each payment.
Shopping carts are usually amount locked, meaning they can't enter their own amount to pay for the object. If you remove the &amount=XXX from the payment url (assuming paypal), then when they reach paypal, it will prompt them for an amount to be sent.
On your end, you will use sql to keep track of each payment, and when the sum of all payments reaches the total, send the item to all payers.
Related
I want to know if there is a way to customize WooCommerce such that the clients could pay the same order with multiple payment methods at the same time?
For example, if one order is worth $100, I want to allow clients to pay $25 with a Visa card, then $75 with a Discover card. So the general idea is to pay one order (don't checkout multiple times), but use more than just one payment method.
I assume there is some way to personalize something, but I want to know where/how to get started with it.
EDIT 1
Just adding a new payment gateway (custom) does not solve the issue. I know how to create a custom payment gateway.
The issue is: how do I allow on ONE checkout for ONE order to get the payment out of 2 or more sources at the same time? For example: $175 cashed in as $50 PayPal + $100 Visa + $25 MasterCard.
There are many clients who would love to have this option, and pay with more cards at the same time!
So, this is not one of those obvious questions as how do I create a custom payment gateway? - that is something easily achievable without spending too much time on it. The multiple payment on same checkout, however, proves to be lengthy / not discussed (I've researched many articles, forums, etc.)
What I would do is to create a custom payment gateway, and in that gateway, create interfaces for ALL the payment methods you want to use.
I would say use something like Stripe for all the CC and then PayPal - that way you will have only two separate ones to handle.
You need to put in an option to pay X amount on each payment gateway on the Checkout screen.
Then in your plugin when someone partially pays, create a coupon for the amount of the partial payment using the Coupon API and apply that.
You will also need an Order Status of Partial Payment or something. You would also need to redirect back to the Checkout page if the order isn't completely paid, instead of the Order Success page.
It's pretty complicated to do this right.
Workaround: You can purchase a gift card on our site for any amount with one credit card. You can then use the gift card and then use another credit card for the balance.
Example: Total price $450
Gift card purchase (Card "A"): $400
Credit Card balance (Card "B"): $50
I know this maybe a duplicate but due to the overwhelming amount of paypal APIs I am having a hard time finding a GOOD answer to my question.
I need to create variable monthly billing per user in PHP. The idea is that a user could sell a number of items with a total sum of sales at the end of the month p. So the billing would be something of the extent MY_PERCENTAGE_FEE * p. The user would then be sent an invoice, and a would be automatically billed via paypal for that amount.
Now, it would be SUPER great if this could be done by creating reoccurring billing and updating the amount at the end of the month. Is that possible? If not what would be the next best way to go?
If you're creating recurring profiles with Payments Pro you can adjust those without any limits. Unfortunately, with Express Checkout you're limited to raising the amount by only 20% every 180 days, so that doesn't normally work out very well. You have a few options of how to get around that.
1) Utilize billing agreements with Express Checkout and Reference Transactions. This would allow you to run an authorization (or an original sale of some sort) for a payer and then from that point on you can use that transaction ID from the original transaction along with a new amount in the DoReferenceTransaction API. Reference Transactions area available with Payments Pro by default, but if you want to use them with Express Checkout you'll need to get that specifically enabled on your account.
2) Use the Preapproval API, which is part of the Adaptive Payments platform. This is similar to reference transactions except that you can create preapproved rules by which you can bill your payers at any time without further approval. This would allow you to process payments for them at any time you need to and pull variable amounts accordingly.
3) Use the Pay API, which is also part of Adaptive Payments, with a split payment (parallel or chained) which would allow you to take your cut in real-time without the need to track balances and submit variable recurring payments. Each time one of your customers is paid for their product/service, you would immediately be paid your share.
I am building an eCommerce site which gives a user the ability to rent
an item for a designated amount of time. If the item is not returned
within that time, the customer is billed automatically for another rent
cycle. If the item is returned the customer will stop getting billed
for additional rent cycles. If the item is bought the customer will be
billed and an additional amount different from the rent price will be
billed to the customer and the customer will no longer be billed for
additional rent. Most of the billing is ongoing and has too many
variables going on to just have a simple subscription payment method.
I think the sequence of transactions can be initiated with a simple PayPal button form which sends information about my IPN script location, Cancel Payment script location and recurring payment script location.
I find that there are some limitations of what PayPal's API's can do. It seems that the recurring payments API is set up for an amount of set payments set over a specified billing period over a set number of times a customer would be billed. I am not 100% sure on this but I think PayPal only accesses the recurring payment API for a customer once for the initial transaction and executes the continuous transactions without checking my websites internal database which might give data to influence parts of the recurring payment script to cancel continuous payments. An example of when this condition should occur is when a customer returns a product or purchases a product which was already being rented out. PayPal has been terrible at getting back to me about technical problems like this. Another problem with PayPal's recurring payments API is a recurring payment subscription cannot be longer than a year so if a customer is renting an item for 2 years then they would only be charged for the first year.
Any advice on how I can implement a payment system like this using PayPal, if it is even possible would be greatly appreciated. I don't want to have make my own payment gateway if PayPal can do this.
I have been developing an online retail shop.
It is written in php and uses paypal and IPN to handle payments.
I have written my own shopping cart. When the user wants to checkout they click on the checkout button which has the standard cart upload function wrapped around the button and the user is taken to paypal to complete payment. Paypal then sends me an IPN to notify me of the payment.
My question is, at what point should I store the order and when should the stock levels be reduced?
The standard process flow is that I have right now is as follows:
User adds item to cart.
If item is now sold out or the quantity added is more than available, the cart is updated to reflect this.
However, stock added to the cart does not reduce stock levels.
User clicks checkout.
The cart is loaded into an order record in the db AND the stock levels are reduced.
User is taken to paypal to complete payment.
(a) User completes payment.
(b) User does not complete payment by either returning to website or going somewhere else / closing browser.
(Optional) User clicks return to website.
User sees a 'thank you, order complete' complete page.
Nothing is processed relating to the order table since paypal will send IPN anyway.
Paypal sends IPN
Update order with the transaction status
As you may see, there are some issues with this process. If the customer leaves the paypal page without completing payment I will have a 'dangling' order and since stock levels are also reduced this stock will not be available to other customers! A solution to this is to manually 'clean' the database every so often.
Alternatives?
option I) Do not store the order in the database until a 'completed transaction' IPN is received, then use the cart info stored in the session to create an order and reduce stock levels. However, sessions can expire and paypal payments might take days depending on payment.
option II) Store the order as is now but do not reduce stock levels until completed transaction IPN is received. This still has the issue of dangling orders but at least no stock will have to be re added again when cleaning up, I'll just have to remove the orders. Another problem with this though is that if multiple people order at similar times and thus collectively their orders contain quantities that exceed stock. This could be quite chaotic when the system receives completed IPNS and then reduces stock levels to negative quantities!
I have looked everywhere on the internet for some sort of help, but it is not mentioned anywhere! Everyone just skips to how IPN should be handled. I just don't understand how other people could not have had this problem?!
Please help!
You're dealing with the same problem that airline reservation systems have for ages. Use the same solution ie
1.Upon user clicking checkout (while being redirected to Paypal)
reduce inventory count
place a timestamp in the database along with a state that this order is temporary
2a. Once you receive an IPN ie know the billing has been successful
change state of the order to permanent
2b. Have a cron job that runs every few minutes to track temporary orders. If temporary orders are from a time greater than what you allow eg 20 mins then:
remove the temporary order from database
undo the change in inventory count
As both a merchant and a developer, I prefer to adjust inventory stock with the IPN, even if that IPN is pending (eg. an eCheck). The chance of 2 customers going through checkout at the same time with your last remaining stock is typically low. If you do have high enough volume and low stock levels (why would you?) then you may want to do something in the cart to place locks on the items for the duration of the session timeout.
Make sure your order processing code returns the inventory to stock if the order is canceled or returned.
I have finally got my paypal system working using IPN and a reservation system to ensure that two people do not buy the same product.
The problem is, the reservations last for 10 mins on my application. If a user reserves the product the 'timer' starts, he clicks pay and ends up on paypals website. He then leaves the computer for 10 mins and comes back. He then buys it. By now though the reservation is up and it is possible that someone else could have already bought it.
Is it possible to send a time limit with the paypal IPN request to stop this happening?
As far as I know, you cannot specify that a transaction has to close within a certain amount of time with paypal.
However, I see two options you can use:
Offer a full refund if they purchase and the product is not available. You would check during the ipn notification of the purchase and if it is not available, then refund. You might be penalized by paypal if this happens a lot, but I don't have a lot of experience with offering refunds.
You can specify that the button needs to check inventory see "Step 2 – Tracking Inventory With Your Buy Now Button" in the standard payments guide. Once the product becomes sold out, you use the api to notify paypal the inventory is zero (if there is an api, you might have to use the website for this), and they should be able to notify the user there is zero inventory. I don't have experience with this either, but it seems more complicated than #1, and I would probably go with #1 if this didn't happen a lot. I think in the end you still end up having to issue a refund if the user goes through with the transaction even after seeing there is zero inventory, but I'm not sure about the wording in the docs.