Love the order ahead use-case: https://developer.squareup.com/docs/orders-api/order-ahead-usecase
Trying to figure out though. It says: "The customer kicks off the process by ordering one small coffee and one chocolate chip cookie using your order-ahead app. The customer chooses to pay using the app and pick their order up at CoffeeCool’s location."
Can the customer therefore "choose" to pay at pick-up? I'd still want the created order to be sent to the POS, so that the kitchen can start preparing it and the customer is not waiting.
Essentially this would be like replicating the "Save" rather than "Charge" option if this order were being manually made at the Square POS.
Currently only orders that have a charge associated to it will appear in the Square app and unfortunately the option to pay at time of pickup isn't currently available.
Yes You Can. You can set it up from the dashboard ( your computer) not directly from the POS. The issue is that it will prompt you to give a name to the order
Related
How do you send a [survey-link] that creates/links to a new instance of a repeating-instrument survey in REDCap?
ie imaging you have customers who should visit you on a regular basis. You have two instruments:
customer
visit [set as a Repeating Instrument + enabled as a Survey]
And you have an alert that regularly sends them a "Time for your next visit" email.
When I send an alert to a customer with [survey-link:visit] it will work the first time. The email will contain a unique URL for that customer's visit. But when the alert is sent a second time, person will open the URL and get a "Thank you for your interest, but you have already completed this survey."
I can manually (via the web admin) create a new instance of their Visit. But how should I do this automatically?
Thank you.
As of version 12.5 this is now supported using a smart variable [new-instance] which, when appended to a [survey-url] or [survey-link] smart variable, will target a new instance of the instrument if it is repeating. In the same release came ASI options around repeating instruments, which allow you to repeat an ASI every X minutes, hours or days, and each successive ASI instance points to the specific instance of the survey instrument. This is useful for daily surveys.
For your use case, [survey-link:visit][new-instance] will do what you want. Send it to them once and instruct them to fill it out as many times as needed, or send it however many times you need to.
====
Yes, this is a current limitation. It has been requested of the REDCap developers to add a smart variable [new-instance] that can be appended to a [survey-link] or other smart variable to instantiate a new instance of a repeating instrument, and they have responded positively.
Maybe the most appropriate workflow here would be for you or the project staff to manually create the visit instance, save it with a date, and have an alert that sends them an invitation to complete the visit details, or whatever you need them to do.
If you want the respondents to instantiate the visit themselves (i.e., make a booking rather than respond to a booking made on their behalf), the only workaround I have personally managed is to enable the survey queue and activate the repeating instrument on the basis of some logic (say, [consent] = 1), and in the survey settings of the repeating instrument, enable the option to Allow respondents to repeat the survey.
With these settings, the survey queue will allow the survey respondent to create a new instance of the instrument themselves by clicking the 'Take this survey again' button (button text configurable in survey settings). They can be emailed their link to the survey queue via an alert using the smart variable [survey-queue-link] or [survey-queue-url].
For extra credit, you could get fancy with the survey queue logic so that the instrument is disabled if, say, the last instance of the survey has today's date, using something like [consent] = 1 and datediff([visit_date][last-instance],"today","d",true) > 0. With this you could prevent them smashing it and adding multiple new visits at once.
I am trying to make a functionnality so that a customer will be able to split his order into 2, in case some articles are temporarily unavailable and if they wish that we send them part of their order first. So the idea is to create 2 new orders and cancelling the old one.
Do you have any idee about how to do this programmatically please ?
What you're describing doesn't sound necessary... You're talking about sending part of the order first... Notice in the Magento Admin once an order is place you can create an invoice, take note that you do not have to invoice everything at one time, the same is true when you create a shipment. You'll need to make sure you're merchant / payment gateway supports multiple partial captures against a single authorization.
However, if you really want to split the orders in two, it is a rather complicated process. We've done it, and its very tricky... you need to modify the opcheckout.js file, you'll need to modify the template since you will have to create seperate shipping methods for each order. You'll need to modify the OnePage controller & Model files very significantly. There are tricky areas in terms of re-executing the totals and making sure data on the order and subsequent quote and address models is precisely what is required by Magento. Maintaining the other checkout functionality requires diligence, such as saving the customer's address when checking out. If you're really going down the path of coding something that splits an order into two orders during the checkout process, feel free to send me a message and we can talk more in-depth and I'll send you some code.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have a website where I've done a "mission generator" to encourage engagement. I've hard coded 3 sets of missions (Easy, Med, Hard).
Easy missions have 6-8 cases that could randomly happen
Update N times your hero (N is random number)
Update specific skill
Rest your hero for a day
etc..
Med and Hard require 1 task which is harder to achieve and adds two from the Easy tasks.
My generator works great but I would like to know how to design the reward system so that it is hard to game by the users.
The problems that I have are sort of:
The user might decide to quickly achieve the tasks and then delete them as soon as they get the "achieved badge"
For example
Update 3 times your hero
Add a new skill
Send a message to another hero
What I see as a problem is that the person might decide to update 3 times, choose a new skill and send a message, then erase the 3 updates (there is such a feature) remove the skill and delete the message that he has send.
So far I've come up with the following ideas but I'm looking for an opinion from someone who has done something like that.
- First approach:
Hard-code a table in the database with columns for each possible combination say
row1 - Updates | row2 - New skills etc...
Downside: I'm afraid that the row could end up very long and it would be hard to manage and add new types of challenges. The whole concept become very rigid.
- Second Approach:
For every task assign a unique id and once a skill or update or whatever is added append that to the task number.
Downside: every member gets 3 daily missions (which could be extended in time) if the generator requires on average 3 updates per mission that makes it to roughly 10 updates per user per day, adding to that the actual records for the updates with the data it adds up pretty quickly for a couple of thousand users. I would say 90% of this data will be useless and will just generate bills.
- Third approach:
Add a column to the table with the updates, skills (and all the other tables which are used in the missions). Then, when the user adds a new skill (for instance) the challenge ID will be added to the column in the skills table, then if the skill is removed the mission will fall back to "unachieved" (same goes for the updates and the other skills)
Downside: This might turn out very messy when the challenge is "put hero to rest for 1 day" because if the generator asks that twice between two days, the user will lose the first achievement of that sort because the challenge ID will be overwritten.
A big question is - what happens when the user decides to cut corners and delete some of their skills. I presume their missions will start piling up? (kind of like a punishment)
Try making some things more dynamic.
For example: You could put the skills in a static checkbox list on the side, and select or deselect them. Then add a button to delete the selected skill, and skills are added to the static checkbox list by selecting a skill on the page itself, outside of the checkbox list.
The skill is then added to the checkbox list as an element.
When you need to rest your character for a day, it's pretty much impossible to do that twice in one day. Make it so that the rest for a day event can only happen once in a day.
This way there is no need to worry about overwriting, and the player doesn't get confused as to why his hero needs to rest twice. Perhaps make the resting bound to a stamina bar that decreases with certain events. When you add a skill perhaps the training can cost stamina. When the stamina runs out his hero needs to rest.
About removing updates and skills:
It is not a very good idea to make things removable right after being added.
Make it so that the skills and updates can only be removed after a certain time.
Long enough to confirm the achievement and store the achievement.
Then they are able to remove their skill and updates and the achievement which was already saved won't disappear.
Sending a message to the other hero:
I have a question about that.
Why would you be able to remove the message.
Is the message sent to another player?
If so, it would make no sense to be able to remove it.
Also, sending a message obviously happens server side since it goes to another player so you can set it to done server side.
I'm working on my enterprise SaaS application and some of my users would like to be charged on a per-seat approach.
I was wondering how to make sure that the access will indeed be limited. I can see right now that people with the same login/password are logging from different IP addresses, different user agents at the same time, even though the company have paid only for one seat.
What would be the best way to implement the limitation from business and technical perspectives? I don't want to be too strict, at the same time I want companies to pay for the number of seats they actually need.
Don't filter by user agent, I think that would be too strict, some people may have a variety of browsers installed. Filtering by IP could also be tricky, some users may have a dynamic IP that changes at regular intervals.
One idea I have would be to force users to install a browser extension, the browser extension could generate a unique ID from something on the operating system. Maybe use a HDD volume number or Windows serial key, anything that will be unique to that computer.
Once you have this unique ID, use it in the back end tracking every time the user logs in. If the user exceeds a certain number of seats you can either block the user account or contact them first.
It would also be a good idea to allow the user a certain amount of freedom, so that if they have one seat then the back end will allow maybe 2 seats for a month (rolling period), this would be in-case the user buys a new pc or installs a new HDD.
Using IP seems a bad idea - people in a LAN will (usually) all have the same IP.
Assuming PHP has no API to access inspect sessions different than the current one - one idea is:
if you're not already doing it, for each login cookie you issue, also issue an unique id (an UUID will serve your purpose)
store those ids somewhere (in java you could store them in the application context, maybe in php you'll need a db table for that - I'm no php expert), together with two timestamps: "session start" and "last activity"
at each request, record the current timestamp in "last activity"
Then, when you get a new request, count how many other active have
last activity >= current session start
last activity >= now - session TTL (only needed if can't prune expired sessions in a timely fashion)
That should give you the number of occupied seats.
Note you will not notice a violation of the number of seats until after the surplus user has logged in and precisely until you see activity in some other session – I don't see any way around this issue since you don't know exactly when a seat becomes vacant (well, you might say it's vacant only when its session has expired, but that seems unfair).
I have a requirement to be able to accept different forms of payment within the same order - ie not just the usual credit card or paypal for the whole thing, but perhaps paypal for one item, cheque for another. I know this sounds quite crazy, but there is a good business reason for the requirement so I can't just push back.
The best way I can think of implementing it at the moment is to have kind of a hub page, where you can "launch off" into multiple flows for each of the payments by opening new windows. I can't figure out a way of doing this in a linear flow as for example you can't guarantee that a user will come back from paypal, so you'd then lose the user completely.
Is there a neater way of doing this that anyone can think of, or can anyone point me to an example of a site that does somethign similar for inspiration?
Even when opening several windows at once, there is no guarantee that the user will complete all payment methods. So you are most probably going to lose a few users or payments. Be sure to send automated e-mail follow-ups for missing payments to minimize this problem. The e-mails could contain links to your payment providers for easy accesss to their outstanding payment operations.
This is a difficult problem, but how many payment processors do you have to go offsite for? Should only be paypal.
In any case, I'd give the user all their payment options on one page, and let them fill in the amount for each processor or payment type. Then the next page would list those they chose, the amount for each, and a link to "Complete this payment".
The link would open in a new window.
You'll have to have a good back end and javascript, as well as user warnings so that the payment page gets updated as each payment is processed. Consider using popup dialogs to show that a payment has completed, or that the order has sat idle for more than 10-30 minutes without complete payment.
Also, consider sending emails and letting the user complete the payments through links in the emails. Send a new email each time a payment is completed, and a final email if all payments are complete and the order is moving forward.
Send an email one hour, and one day later for uncompleted orders with remaining payments required, that also give them the option of choosing different payment options for the remainder.
Email isn't best (lose more orders that way due to changing minds) but it's good for the type of transactions you're thinking about.
Personally, I'd do it like this:
Let the user fill their basket in the ususal way
Allow them to add payment types and amounts to a list (2nd basket almost)
When the payments balance against the basket, start processing the payments
For external sites, try a frame which has a progress indicator at the top.
In an ideal world it wouldn't be linear. But a lot of users might lose a spawned window, or get confused by the parallelism.
Better to stick to established IxD principals and rely on good feedback instead. Give the user control from the outset and keep it transparent.
Lastly, start the payment process with the most immediate (e.g. paypal) to reduce users giving up. (COD should come last!)
Hope this helps,
Tom
If possible, just separate your order into separate smaller orders based off of the payment selections of the user.
And don't do it linearly. If anything you could open up each payment processor in a separate window so that you maintain presence.
I would take an approach where the whole order is broken down into sub-orders for each of the necessary payment methods. You can load the PayPal portion, the check portion, etc. and process them separately. It's important for the user to know how much is being charged to each of their payment methods, so it makes sense in this case to present the whole order as broken down by payment method (versus displaying as a unified order).
Implementation would be easiest if it's always a certain subset of items that is forced to any payment method. If this differs by user, or if it's when the order reaches a certain amount, the situation could become much more complicated. Can you be more specific about your approach?
Processing Multiple Order Payments
Give the user the option to make a payment for a pending order using any of your payment types.
Let the user specify an (Amount <= [Order Total] - [Payments Received]), if that is part of your requirement.
If the order is still pending after you process the payment (see how below), take them back to step 1 to rinse and repeat.
How to store and process each payment made:
Use a Payments table to store all order payments, the PaymentMethod used and its Amount with its CurrencyCode.
When a payment is received for an order, store the payment and sum all received amounts converted into your base currency as [Payments Received].
If [Payments Received] >= [Order Total], mark the order as Paid. Or, if dealing with double-converted foreign exchange rates, check if it is correct to within a small-enough margin, eg 0.5%.
Optionally, convert any overpayment into prepaid credit for the client.