Receipt Emails
-
When a purchase/invoice/cart is done, there can be multiple products on a single order.
-
When paid, a single “Receipt” email is generated which is listing everything individually with payment info, invoice, what you’d expect a receipt to be.
-
re:Members (formerly Impexium) doesn’t have a consistent name/reference for this, but “Receipt” is best.
Confirmation Emails
-
Each individual product can then have a Confirmation Email in addition to the receipt.
-
This is designed to be a more visually designed email with more details. “Thanks for being a member, here’s what you can now do.” type of message.
-
If multiple products are on a single payment, and each of them have confirmation emails, the person will be getting 1 receipt, but possibly multiple confirmations.
-
There is a BCC setting for Confirmation Emails, typically used for an ALTA email address, such as TIPAC@alta.org, to get a copy.
-
NOT DOCUMENTED is that if you add a BCC to the Confirmation, save it, then turn it OFF, that BCC still applied to the RECEIPT.
Transaction Email Compliance Rules
-
It’s a compliance requirement for credit card transactions to get the receipt email, but not for checks.
-
There used to be a checkbox so staff could choose to NOT send that if they didn’t want to. That is no longer there due to the compliance rules.
-
However, that is also labeled as a CONFIRMATION email. It’s actually receipt, confirmation as well if set, basically the same thing that the user gets when doing it themselves.
-
We have explained to re:Members (formerly Impexium) we understand the reason, but there are valid reasons this blanket setup isn’t ideal.
-
We’re hoping they will give the ability to change the email for the receipt to someone ELSE, so that compliance is met, someone is informed of the purchase with the receipt, but not necessarily the person that the product is actually on, since that might not actually be the purchaser.
-
Mean time, Sally had worked out a workaround to remove the email address from the record, do the transaction which wouldn’t go to anyone, then add it back. Not ideal. (And technically breaks compliance)
