Member
Member related services
Depending on your needs, Lobyco can maintain and expose various user-related data with the supporting Lobyco services. These can be used in the Mobile App, Admin Tool, or exposed to 3rd party services.
- Member data: ID, email, address, etc.
- Bonus: money bonus (points) accounts, history, full ledger
- Store: favorite store
- Receipt: generated based on purchase transaction log
- Consent: acceptance of different versions of the App, terms and conditions, data protection consent
- Card Payments: payments done with cards registered in the App.
- Loyalty Card: multiple virtual cards can be generated for a user and used for check in at the POS

Member data
Member Service provides all the needed endpoints to manage members.
POST /v1/membersto create new members, minimum data can be configured, and optional data can be easily extended
GET /v1/members/{memberId}to get member information
POST /v1/members/importfor importing members already created in other systems
Member Overview tab from the Admin Tool contains editable information. The Admin can view and edit member personal data, preferred store (that may be used for sending offers to members that are available in that specific store), view cooperatives membership, and others.
This information is also visible to the user in the Mobile App, usually in the Profile section.
Optionally, a member can be an employee, and this might be configured to receive an additional 'employee' bonus, in case the bonus service is deployed. Employee bonus percentages may differ for members and can be uploaded by API endpoint.
Members can belong to local cooperatives that may provide additional benefits to members like bonuses of a specific type. In order to make member a part of some cooperative it is needed to upload a member identifier and cooperative name using the Member service endpoint.
Admin can view if a member is an employee or belongs to some local cooperatives, managing of this info can be done only by API endpoints.
Member Agreements
Admin can manage available consents for members and change their versions, and acceptance state. Consents can be set up in the Consents Admin tool, their types are configurable and can vary depending on customer needs.
During the sign-up process, a new member faces multiple types of consents: regular such as email, SMS, and agreements - terms and conditions. Regular ones can or cannot be accepted during signu. The user can change their states can be easily changed on the mobile app Profile > Permissions screen.
During signup, the Terms & Conditions agreement must be accepted by the member to be able to finalize the registration process. The agreement can be read during signup or on Profile > Permissions > Terms&Conditions screen in the mobile App by the enrolled user.
Once the conditions of a specific version are accepted, then neither member nor admin can change its status to not accepted. When a new version (not revision) of terms and conditions is created in the Consents Admin tool, then members will get a popup notifying them about updated Terms & Conditions that must be accepted to be able to continue using the mobile app.
Member Loyalty cards
A member can get one or multiple physical or virtual cards. The member can check in at the POS using an active loyalty card and therefore get benefits or redeem coupons when completing a transaction. Admin may do several activities in the Admin Tool: activate, deactivate, and add a new loyalty card to a member.
The list of member physical or virtual loyalty cards is listed in the Member Admin Tool.
Member changes history
Member-related changes along with the date of creation and changes maker initials can also be found in the Member Overview screen. Usually, such events, as member creation personal data changes done by the member or admin, member deactivation/activation, and preferred store changes are tracked here.
The Admin can add some notes explaining the reason of made changes, but also add some notes to the user profile. These notes can be created based on user interactions. For example, following a Customer Service request where the member raises an issue.
Member App Payments
Mobile App supports card payments or different wallets (e.g. Apple Pay, Google Pay, Mobile Pay) payments. Once checked in the user can pay with a card within the App.
Payment history can be viewed in the Admin Tool inside the App Payments tab. It is possible to filter payments by date of creation, receiptId, type (payment or refund), and status, and also change payment statuses by Admin.
Admin can see more detailed info about payment methods when expanding payment details. The Admin can also do different actions
- Capture or Cancel payments in WaitingCapture status
- Cancel payments in WaitingMemberConfirmation status
- Refund Captured payments. During the Refund, a new transaction of refund type is created, and the original captured transaction is marked with 'R' as refunded. The reason and author of the refund are shown on the tooltip when hovering the mouse over the refund statement.
Member receipts
Member receipts can be viewed in the Receipts tab from the Admin Tool, but they are also visible in the Mobile App for the user. Admin can filter them by date, export in CSV file, and view details.
The admin can view each receipt in the same view as member sees on their mobile App and this is useful for investigating Customer Service requests.
Receipts are visible to the member after the transaction is loaded into the Lobyco system.POST /v1/purchases endpoint can be used to upload POS transactions - either directly by the POS or via a Lobyco integration layer.
Member deactivate
In order to suspend a member's ability to use the App, an admin can deactivate the user from the Member Admin tool. They can also activate members back if needed.
Statement about member deactivation along with the provided reason will be shown in Changes section.
If the member was deactivated, the logged-out member will not be able to log in to the mobile app. The logged-in member will see a screen about deactivating and will be logged out once they close the screen. To allow members to continue to use the app admin should activate it from the Admin Tool.
Consent
Loyalty benefits and offers revolve around handling user data. Thus, user needs to give consent before managing any of it's data. We have grouped consents into 2 different categories:
- Member-level consents
- Device-level consents
Member consents
Member consents are consents that the user has given for data shared across multiple devices, such as mobile, web pages and our backend services. These consents are given on sign-up, even when membership is obtained in the store. This type of consent can also be categorised into 2 groups:
- Necessary consents (Membership, email from preferred store, etc)
- Optional consents (CO2/Push/3rd party consents, etc)
Necessary consents
They are requested during the user sign-up process. They are mandatory, the user cannot finish the sign-up flow without accepting them. They cover everything related to the functionality of our entire services and products, as they relate to the entire underlying data processing that we do on the backend.
Optional consents
These are additional consents for extra product-specific functionality. Some of them cannot be turned off after being initially enabled:
- Prime subscription handling
- Scan&Pay terms of use
- Using marketing data for Facebook or other marketers
Some of them can be toggled on/off after being enabled, such as:
- CO2 footprint calculation
- Email communication
- Push notifications
Device consents
Device consents are given by the user for data handled locally on each device and/or exposed to 3rd party SDKs or other services. These can again be broken down into multiple categories:
- Consents for sharing user data with 3rd party services
- Consents for accessing the device/OS specific data
- Consent for advertisement
- Consents for sharing user data with 3rd party services
There are implemented on the mobile apps through the Data Privacy Manager component. This component sets a specific privacy level on the device and 3rd party SDKs/services decide what kind of user data / user identifiable data they have access to.
The Barcode API provides a mechanism to decode a raw barcode and extract its corresponding inner data. In order to achieve this, we make use of templates, which contain general structural details and rules about how to decode the barcode. A template has the following characteristics:
- Name
- Type, indicating what if it is an article barcode or a voucher for instance
- Minimum and maximum length
- Code identifiers and where to find them within the barcode
- List of rules about how to extract the data tokens
- List of validation rules
In order to decode a barcode, the following flow is applied:
- Try to match the barcode to the templates
- If more templates are available, we choose one of the matching templates
- Once we have chosen a template, we can use its rules to validate the barcode
- Regardless of whether the barcode is valid or not, we proceed to extract the data via the template data extraction rules