You can view a step-by-step guide and a video example here
To prevent issues of “dead emails” we highly recommend that merchants use a group based email address that multiple people have access to when initially setting up their accounts.
firstname.lastname@example.org for example. We recommend adding this to you onboarding procedures as a recommendation to pass on.
Currently we have a manual process on Violet’s end that allows us to accomplish this task, however there are a few security related considerations.
- The new email must be @companydomain.com. To avoid scams, we cannot transfer a merchant to gmail.com email address or any other public email provider.
- The merchant cannot yet have setup their payout account; this is to prevent financial fraud. You can check this in the Merchants tab, if the
Payout Accountis marked “Needs Attention” they have not yet created their account.
- For cases where a payout account exists, we may require the merchant to complete additional verification steps before we can complete a transfer.
We have a project in our backlog to support merchants transferring ownership themselves, but for now it will be a manual process.
Assuming they fulfill the above conditions, to complete this process we will need from you:
- The MerchantId and Name
- The original email used (optional but useful)
- The desired new email (must meet above conditions)
- A screenshot of their payout account tab, to verify the above conditions. Make sure the merchant name and Id is visible in the shot.
Contact us with the above information and we will take a look.
Write Customers allows the order to be associated with a customer record in their system. This comes with things like their email, etc. Most Merchants want to make sure that data is carried through, and in order to do that, we have to be able to Write Customers as a part of the Order Creation process in their system.
We’ve historically requested this scope. Shopify did eventually give us the ability to write customers under the
write_orders scope however we’ve continued requesting the
write_customers scope for forwards compatibility. On July 1st Shopify will be rolling out a new suite of customer protection rules that will impact API functionality and having the
write_customers scope ensures that there will be no disruptions to our integration with Shopify when this goes into effect. We will likely revisit our scopes once we’ve reached July 1st. If it’s safe to do so we can likely reduce this scope down to
We prefer to over-optimize on scopes as asking all merchants to go back and change their scopes after onboarding has been a painful experience in the past. If the merchant is not comfortable with
write_customers, they could complete the onboarding in Violet Connect, get past the scope validation part, then go back into their Shopify Custom Apps view and uncheck the
write_customers scope. We don’t write any customers during that brief window that we have the
write_customers scope so there will be no impact on their system. If we find that we require the scope once Shopify’s changes go into effect on July 1st we can then explain the need for it to the merchant and ask them to re-enable the scope for
Merchants can view their payout on Stripe’s Stripe Express Dashboard.
- Have the merchant go to https://merchant.violet.io/settings/payments
- They will need to login with the email they created their merchant with originally
- Press the “Manage on Stripe” button
- They will be directed to the Stripe dashboard
- They will need a text code from the phone number provided during setup
- Once on the dashboard, they can click on the transactions tab to see payments from violet as well Stripe Payouts to their bank account
- They can filter by date and export the data to CSV
Product modifiers are selections available on a product that do not map to a specific sku. Options on the otherhand are selections that lead to variants, each mapping to a specific sku. Common options include colors and sizes. Modifiers are more rare but an example might be a text field allowing a user to enter their Initials for personalization. Obviously, no one would create a sku for every possible set of initials, leading to the name modifiers since it modifies an already existing sku instead of creating a new one.
Unfortunately, Violet does not currently support modifiers, we currently only support product options. This is mainly because there is not broad support for modifiers across ecommerce platforms so adding this feature would only have piecemeal support in our supported platforms. We are open to discussing this more if this is a feature that is critical to your business.
Additionally, currently BigCommerce, a platform that does support modifiers, has a bug in their API preventing us from completing a checkout with modifiers.
Only merchants have tools to change their commission rate. Channels do not have the ability to change commission rates from their end, and Violet typically does not change it from our end unless there’s an emergency.
The reason we do this is because the merchants are the party needing to get paid for the product that is purchased & shipped. We are exploring other ways to do this in the future.
During onboarding through your Violet Connect dashboard, merchants select a commission rate that we expect has been pre-negotiated between you and the merchant. Violet trusts that the merchants you bring onboard would abide by the contracts they have signed with you, similar to how they would expect you to abide by the same contracts.
Consider the reverse scenario:
If you were able to change the commission rate for a merchant, set it to 100% without their agreement and then continued to submit orders that they fulfill, they would be releasing inventory and eating production costs while earning nothing.
To prevent scenarios such as these, we currently only allow the merchant to change their commission rate. Any time a merchant changes their commission rate, you will be able to see it on your Channel Dashboard. We have plans to build a better notification experience if a Merchant does indeed change a commission rate. We will also have plans to build better tooling to ensure that neither party can maliciously try and impact the other, as this is something we have brought up internally in the past, as well.
That being said, if you do have a merchant that is out of compliance, we are releasing an API soon that lets you unsubscribe to all their offers so that you don’t list them on your app, without breaking the connection to the merchant. Prior to launch of this new feature, you can reach out to the Violet team to take care of this for you should a compliance issue pop up. We’ll let you know when this is available to use.
We encourage channels to create free test stores they can own and manage and then connect those test stores to their test mode channel. This will allow you to manage your own test products, initiate test refunds/returns for your orders and get some experience working with Violet Connect before you start onboarding real merchants.
See a guide here
If you see the Channel Login Detected dialog, that means that an account with the entered email already exists in Violet as a channel account. An account (email) cannot be both a merchant and a channel.
If you are a channel and you are trying to create a test store, you must use a different email address for the test merchant. Adding
+merchant before the @ is often an easy way to accomplish this as the email will still go to the same inbox. E.g. email@example.com
If a real merchant encounters this issue, that almost certainly means they accidentally created a channel account instead of following the Violet Connect flow to connect to your channel. In this case they will need to select a different email account to complete their Violet Connect flow.
If they are adamant that they want to use the already used email for Violet Connect, please contact Violet Support and explain that a merchant accidentally created a channel account and they want their email address made available to be used for their merchant account. Please provide the email address in question.