Difference between revisions of "Same as shipping logic"
m (→Guest checkout) |
|||
| Line 43: | Line 43: | ||
* the flag becomes true and | * the flag becomes true and | ||
* the Sender | * the Sender entity is updated with Recipient details | ||
upon Order creation. | upon Order creation. | ||
| Line 49: | Line 49: | ||
==== Logged-in checkout ==== | ==== Logged-in checkout ==== | ||
If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'' the flag becomes true and the Sender | If previously a new Sender was added to the Checkout, then when choosing ''Same as shipping'': | ||
* the flag becomes true and | |||
* the Sender entity remains in the Checkout, but will be removed upon Order creation. | |||
** we don't remove it because the flag tells us to ignore it. | |||
== Add new billing address == | == Add new billing address == | ||
Revision as of 11:09, 20 February 2022
Prerequisites
The Recipient and Sender are linked to a User, if any. A user may have more than one Recipient / Sender. Why this is important? In the checkout process there are two scenarios:
- Guest checkout
- Logged-in checkout
- Abandoned checkout URL process
1. Guest checkout
In this scenario when editing the Recipient / Sender details they are always overwritten. In other words, a Guest checkout will have one Recipient and one Sender object. These Recipient and Sender are not linked to a User.
2. Logged-in checkout
In this scenario the customer has two options: Add a new address and List previously saved addresses.
- With Add a new address a new Recipient / Sender is created in db and linked to the Checkout.
- When picking a previously saved address a different Recipient / Sender is linked to the Checkout.
3. Abandoned checkout URL
This is affected by whether the Checkout was previously done with scenario (1) or (2).
When resuming an Abandoned checkout, you can edit only data linked to the current Checkout. Therefore, if the checkout was done by a logged-in user you no longer have access to the previous Recipient / Sender lists.
So, when editing a Recipient / Sender the entity linked to the Checkout is therefore overwritten.
The "Same As Shipping" workflow
When choosing the Billing Address (Sender) the Customer has 2 options:
- Same as shipping address
- Add new billing address
Same as shipping address
Guest and logged-in checkout scenarios do not affect the Same as shipping logic. With this logic no Sender is created in db, but a flag is marked. As a result, upon checkout completion a Sender will be created and attached to the Order.
NOTE: Recipient fields must match Sender's. Results that Recipient must have Company and Company VAT fields.
Guest checkout
Previously a new Sender was added to the Checkout, then with Same as shipping:
- the flag becomes true and
- the Sender entity is updated with Recipient details
upon Order creation.
Logged-in checkout
If previously a new Sender was added to the Checkout, then when choosing Same as shipping:
- the flag becomes true and
- the Sender entity remains in the Checkout, but will be removed upon Order creation.
- we don't remove it because the flag tells us to ignore it.
Add new billing address
In this case the same_as_shipping flag is set to false (0) and a new Sender is created and added to the Checkout.