BelivrHQ is operated by PappyCoder Technologies Limited, a company based in Nigeria ("BelivrHQ", "we", "us" or "our"). This Privacy Policy explains our handling of personal information through our website, account services, church management platform, support channels and connected features. It also explains the different responsibilities of BelivrHQ and the churches that use the platform.
This Policy is a notice about data processing. Reading it, visiting the website or accepting our commercial terms does not, by itself, provide consent for every use of personal information. Where consent is required, it must be obtained for the relevant purpose. Mandatory privacy rights remain available regardless of any contractual limitation.
1. Scope and application
This Policy applies to website visitors, account holders, church administrators and staff, people who contact us, and people whose information is entered into a BelivrHQ workspace. It covers information collected directly, supplied by a church or another authorised person, generated through use of the service, or received from a connected provider.
A church may operate its own website, publish a form, organise an event, collect giving or communicate through a provider connected to BelivrHQ. That church must provide its own privacy information for its activities. Our Policy does not replace the church’s notices or the notices of payment processors, communications providers, video platforms and other independent services.
The Nigeria Data Protection Act 2023 and applicable implementing instruments inform this Policy. Other mandatory privacy laws may also apply depending on the people, organisations and processing concerned. We do not represent that the platform is automatically suitable for every country, sector or regulated use.
2. Who is responsible for your information
For information processed to run our business (such as account contact details, subscription payments, enquiries, platform security and our own legal compliance), PappyCoder Technologies Limited generally acts as a data controller, determining the relevant purposes and means of processing.
For information a church submits or generates in its workspace, the church generally acts as controller and BelivrHQ acts as processor on the church’s documented instructions. An authorised administrator’s use of the platform and agreed settings form part of those instructions. The precise legal role depends on the actual activity, not only the label used in this Policy.
A church’s administrators manage access to its workspace, including branch assignments, roles, permissions, invitations, exports and public sharing. Staff, volunteers or contractors with access act under that church’s authority. BelivrHQ support cannot automatically override a church’s permissions or disclose its records merely because a person asks for them.
If your request concerns a church record, contact the church first where practical. You may also contact us directly. We will identify our role, verify the request as appropriate and assist or refer it to the responsible church without preventing you from exercising rights against us where we are legally responsible.
3. Categories of information we may process
| Category | Examples and context |
|---|---|
| Accounts and administration | Name, email, phone, church name, denomination, address, staff role, branch, account status, invitation details and administrator settings. |
| Authentication and security | Account identifiers, password authentication handled by the authentication provider, session and token information, verification events, authenticator configuration, recovery mechanisms and security audit events. |
| Church people and relationships | Member and visitor names, contact details, photographs, dates of birth, family and household relationships, membership information, assignees, groups, departments and branch assignments. |
| Ministry activity | Services, events, registrations, ticket and check-in records, attendance dates, appointments, volunteer information, sermons and media, engagement summaries and permitted pastoral records. |
| Financial and transaction information | Giving amounts and dates, donor links, categories, payment method, currency, references, receipts, transaction status, subscription plan, billing cycle, payment confirmations and relevant provider authorisation references. |
| Forms, files and communications | Responses to church-created forms, attachments, imported spreadsheets, uploaded files, message content, recipient details, delivery status, enquiries and support chat messages. |
| Device, service and diagnostic information | IP address, browser or device characteristics, timestamps, request and error information, security signals, cookie or storage identifiers and usage information needed to operate or troubleshoot enabled features. |
| Connected services and assistant questions | Provider settings and credentials supplied by an administrator, relevant callback data, and questions or recent question context submitted to Ask BelivrHQ when that feature is used. |
Not every category is collected for every person. The enabled features, selected plan, church settings, administrator choices and information actually supplied determine the records involved. Churches should configure forms and imports to collect only what is necessary for a stated purpose.
Online payment checkout is handled by the applicable payment provider. Our ordinary checkout is not designed to collect or store complete payment-card numbers, card security codes, banking passwords or payment PINs. We may receive transaction references, status, payer or billing details and provider authorisation tokens. Do not enter card credentials into free-text fields, support messages or church records.
4. Where information comes from
A person who supplies someone else’s information must have appropriate authority, provide necessary notices and establish a lawful basis. Knowing someone’s contact details, being a church member or holding an administrator role does not automatically authorise every use of that person’s information.
- You provide information when you register, sign in, configure a workspace, upload a file, complete a form, make a payment, ask a question or contact us.
- A church administrator or authorised staff member may invite you, import your details, record your attendance or giving, maintain a visitor record or add information about your relationship with the church.
- Connected providers may return authentication results, payment verification, transaction or delivery status, webhook events, file information or other data needed for the configured service.
- The service generates operational records, such as creation and update dates, access and audit events, calculated totals, security checks and diagnostic information.
5. Purposes and legal grounds
| Purpose | Grounds and responsibility |
|---|---|
| Create accounts and deliver the subscribed service | Performance of a contract with the relevant customer or steps requested before a contract; other appropriate grounds for individual staff contacts where they are not personally party to that contract. |
| Operate security, prevent abuse and investigate incidents | Legitimate interests in protecting the platform and people, balanced against individual rights, and legal obligations where applicable. |
| Collect subscription fees and keep business records | Contract administration and applicable financial, tax, accounting or legal obligations. |
| Answer enquiries and provide support | Steps requested by the person, contract administration or proportionate legitimate interests, depending on the enquiry. |
| Maintain church records and deliver church communications | The church’s documented instructions and lawful basis. Sensitive data and electronic marketing may require additional conditions or consent. |
| Improve reliability and diagnose defects | Proportionate legitimate interests in operating a dependable service, subject to privacy safeguards and consent where a particular technology or law requires it. |
| Send optional promotional communications | Consent where required, or another lawful permission where available, with an appropriate way to object or unsubscribe. |
| Meet binding legal requirements and handle claims | Legal obligations, lawful regulatory requests and the establishment, exercise or defence of legal claims where applicable. |
We do not treat the fact that processing is useful as a sufficient legal ground. A church must determine the lawful basis for each of its purposes and any additional condition needed for sensitive or children’s data. Contractual necessity does not automatically justify processing the personal information of every member or visitor.
Where we rely on legitimate interests for our own processing, we consider necessity, proportionality and the effect on individuals. Where we rely on consent, withdrawal affects future consent-based processing but does not undo lawful processing already carried out or remove another valid retention obligation.
6. Religious beliefs, pastoral information and other sensitive records
Being identified in a church database can reveal religious beliefs even when a record does not contain a field labelled ‘religion’. Pastoral notes, family circumstances, health information and other records may create additional sensitivity. Churches must assess those risks, collect the minimum necessary, identify a lawful condition for sensitive-data processing and limit access to people with a legitimate need.
A church’s religious or charitable purpose does not create an unrestricted permission to collect, disclose, market with or publish sensitive personal information. Any statutory exception must be evaluated against its actual conditions. In particular, public disclosure or sharing with unrelated organisations requires separate consideration.
The platform includes permission and branch controls, and selected categories of secrets or records receive additional protection. This does not mean all stored information is end-to-end encrypted or inaccessible to every authorised service operator. Administrators must configure permissions carefully and avoid placing highly confidential information in ordinary messages, AI questions, public forms or broadly accessible attachments.
BelivrHQ is not a medical records system, crisis response service, safeguarding authority or substitute for professional counselling. Do not use it to bypass professional confidentiality requirements, mandatory reporting duties or legal restrictions on particularly sensitive information.
7. Children and people requiring additional protection
An individual creating or administering a BelivrHQ account must be at least 18 and legally capable of acting for the relevant organisation. Children may nevertheless appear in church records, such as family, attendance or event records, under the church’s responsibility.
Before entering a child’s information, the church must determine whether parental or guardian authorisation, age or authority verification, an appropriate legal exception, or another safeguard is required. Only information needed for the specified activity should be collected. Photographs, family contact details, health information and public sharing require particular care.
Parents and guardians may contact the responsible church or our designated contact to raise a concern. We may need to verify the requester’s authority and coordinate with the church. We will not disclose a child’s record to an unverified person or assume that every person claiming to be a relative has access rights.
9. Technology providers and optional integrations
| Provider or category | Role and information involved |
|---|---|
| Vercel and hosting infrastructure | Website or API delivery, request processing, network and operational information. |
| Supabase and PostgreSQL infrastructure | Authentication, database or file-storage functions according to deployment configuration; account information, church records and uploaded assets relevant to those functions. |
| Redis / Upstash infrastructure | Caching, security controls, counters or queue-related functions according to the configured deployment. |
| Resend | Platform account, invitation, password-recovery and company billing or notification email delivery. Authentication confirmation may also be handled through the authentication provider’s configured email service. |
| Flutterwave; Paystack where applicable | Platform subscription checkout or historical payment verification, and church-selected giving or event payments. Payment handling and merchant responsibilities depend on the transaction. |
| Sentry, when configured | Error and performance diagnostics. The application applies redaction to selected request, account and diagnostic fields; diagnostics should not be treated as a complete copy of church records. |
| Tawk.to support chat | The support widget for eligible signed-in administrators on supported workspace or help pages; chat text, contact details voluntarily provided and provider-generated device or session information. |
| OpenAI, when AI synthesis is enabled | Assistant questions, recent question context, selected product references and verified role/plan/access context required to produce product guidance. |
| Church-selected communications providers | Resend, SendGrid, Mailgun, Termii, Twilio or Meta services where supported and enabled; contact destinations, message or call information, delivery status and required credentials. |
| Other church-selected destinations | Authorised webhook endpoints, embedded media services, downloaded files or other destinations chosen by the customer. |
This table explains providers and provider options reflected in the product; it does not mean every provider receives every record or is enabled for every church. Available integrations and deployed providers can change. Contact us for information relevant to a particular feature, processing arrangement or proposed new service provider.
A church must review its own providers’ terms, privacy notices, locations, charges and permissions before enabling an integration. Disabling an integration can stop future application use but does not necessarily delete data already held by that provider or cancel the church’s separate provider contract.
10. Ask BelivrHQ, analytics and calculated indicators
Ask BelivrHQ is a product guidance feature. Depending on configuration, it can answer from product references or request an AI-generated explanation. When external synthesis is used, the submitted question, recent user-question context, selected references and verified access context are sent to the configured AI provider. The current integration requests that the provider not store the response as a stored API response; that setting is not a promise of zero provider retention for all operational or security purposes.
The assistant is not given general tools to inspect member records, make payments, change permissions or act on your behalf. Nevertheless, text you type can itself contain personal information. Do not submit passwords, payment credentials, pastoral notes, health details or identifiable member information that is unnecessary for a product question.
Enabled reporting or scoring features may calculate attendance patterns, engagement summaries or follow-up indicators from church activity. These are administrative indicators that can be incomplete or wrong. The church must explain its use where required, check the underlying information, provide meaningful human review and avoid treating a score as a determination of a person’s faith, health, entitlement, character or suitability.
We do not intend these features to make legally or similarly significant decisions about people solely by automated means. If you believe a church is using them that way, contact that church and you may also contact us. Applicable rights relating to profiling, objections and human review remain available.
12. Service messages and church communications
Account verification, invitations, sign-in security, password recovery, subscription confirmations, renewals and important service notices are operational communications. They are distinct from optional marketing. Some are necessary to provide a requested account or transaction and cannot be disabled while retaining the relevant function.
A church controls its own broadcasts and member communications. It must establish an appropriate permission or consent, identify the sender, honour objections and opt-outs, and comply with the relevant channel’s rules. BelivrHQ does not convert a contact upload into permission to send promotional or sensitive messages.
If an unwanted message relates to a particular church, contact the church or follow its supplied opt-out instructions. Contact us about suspected abuse of the platform. We may need the sender, date, delivery channel and a limited copy of the message to investigate; avoid forwarding unrelated sensitive records.
13. International processing and transfers
Hosting, authentication, storage, monitoring, support, AI and communications providers may process information outside Nigeria. A user or customer may also access the service or export information from another country. Unless expressly agreed in writing, no subscription plan promises that all information stays in Nigeria or in one particular region.
A transfer requiring a legal safeguard must be supported by an applicable transfer basis, such as an appropriate level of protection, recognised contractual or other safeguards, or a specific lawful exception. A church’s choice to use an overseas provider does not remove that requirement. We do not treat acceptance of this Policy as blanket consent to every international transfer.
Contact us for information about the processing arrangements relevant to your use. If a customer needs a particular residency commitment, transfer instrument or additional processing restriction, it must be agreed before that customer relies on the platform for that requirement. Provider locations and contractual safeguards should be assessed for the actual deployment rather than inferred from a provider’s brand name.
14. Security and confidentiality
Our application uses measures intended to protect information, including authentication, permission and church/branch scope checks, session controls, security logging, protection of selected secrets, and encrypted transport where configured for production. Selected integration credentials, authenticator secrets and pastoral content have additional encryption controls. Their existence does not mean every category is end-to-end encrypted, that a security incident is impossible, or that a regulatory certification has been obtained.
The customer must use strong unique passwords, enable appropriate multi-factor authentication, review access and invitations, protect its own devices, limit exports and promptly remove access that is no longer needed. Shared accounts, unmanaged downloads and incorrect public-sharing settings can defeat otherwise appropriate safeguards.
Report suspected unauthorised access promptly through the designated contact. We may verify authority and use a secure channel before exchanging evidence. Do not send active passwords, secret keys, recovery codes or entire member databases in ordinary email. Where a personal-data breach triggers legal duties, we will assess it and provide required notices or assistance without undue delay and within applicable legal time limits.
15. Retention, inactivity and deletion
Information is retained according to the purpose, customer instructions, the status of the relevant account or record, legal requirements, security needs and legitimate claims. A stopped subscription does not itself mean that every underlying church record or payment record is immediately deleted. Deleting a login is different from deleting all business records associated with that person.
Current maintenance routines include removal of inactive member records that have not been updated for more than approximately 365 days and audit logs older than approximately two years when the applicable background jobs run. The inactive-member cleanup can also remove linked records. These are application housekeeping settings, not a statutory retention period or a guarantee that all related copies are deleted on a particular day. Deployment, job operation, record relationships and lawful preservation requirements can affect execution.
Financial, subscription, dispute, legal and security information can require different periods. A valid erasure request, legal hold or specific customer processing agreement may require a different outcome from ordinary housekeeping. We assess the relevant category and legal basis rather than assuming that all information has the same retention period.
Some records are first archived or deactivated and can remain accessible to appropriately authorised users. Permanent deletion may be irreversible. Copies may also exist in exports, recipient inboxes, the customer’s systems, provider records or backups. Where a retained backup contains deleted information, it should remain protected and subject to its applicable recovery and replacement arrangements; restored data may require deletion instructions to be applied again.
We do not publish a universal backup-erasure deadline or promise a fixed post-termination export window that is not supported by the applicable agreement. Customers should export necessary records while access remains available and contact us before closure to agree any assistance, return or deletion arrangements. We will not retain identifiable information indefinitely merely because no fixed period appears in this Policy.
16. Your rights and choices
Subject to the applicable law, our role and legitimate exceptions, you may be entitled to exercise the rights listed below.
Not every request requires release of an entire church database, another person’s information, security secrets or legally privileged material. We may need to redact, separate or preserve information to protect other rights or comply with law. Where we refuse or limit a request, we will explain the reason to the extent legally permitted and identify available review or complaint options.
Your church can often correct ordinary records directly. You do not have to pay for a subscription or use an administrator-only chat channel to raise a privacy request with us. Requests concerning our own controller activities should be sent directly to our designated email.
- Information about whether and how your personal information is processed, and access to relevant personal information.
- Correction of inaccurate or incomplete information, and erasure where the legal conditions are satisfied.
- Restriction of processing, objection to particular processing, and objection to direct marketing.
- Withdrawal of consent for a consent-based activity, without affecting lawful processing before withdrawal.
- Data portability where the legal requirements and scope of that right apply.
- Human intervention, an opportunity to express your view and appropriate review of qualifying automated decisions.
- A complaint to the relevant supervisory authority or another remedy available by law.
17. How to make a request
Email lucasdeekay98@gmail.com with the subject “BelivrHQ Privacy Request”. Describe the request, the church involved where relevant, the email or other identifier associated with the record, and a safe reply channel. Provide only the information reasonably needed to locate the record and understand the request.
We may request proportionate proof of identity, authority or guardianship before acting. A rights request is not an instruction to send a password or provide excessive identification. If ordinary email is unsuitable for the evidence involved, ask us to arrange an appropriate channel before sending it.
We will respond without undue delay and within the time required by applicable law. Where a lawful extension, clarification, refusal or referral is necessary, we will explain it as required. Rights requests are ordinarily handled without charge; a fee or refusal will be considered only where the relevant law permits it and with the required explanation.
18. Public links, exports and connected destinations
A public form, publicly available media asset, external link, receipt attachment or export may be accessible outside the ordinary workspace permission controls. Anyone receiving an exported file or forwarded link may retain another copy. A browser download cannot generally be recalled from another person’s device through BelivrHQ.
Customers must check recipient addresses, branch selections, link visibility and the fields included in an export before sharing. People completing a public church form should read the church’s explanation of collection and avoid submitting unnecessary confidential information. The church is responsible for the questions it creates and the lawful use of responses.
Third-party sites and embedded services apply their own practices when you access them. We do not control those practices solely because a link or embed appears in BelivrHQ. This does not remove any responsibility we have for our own selection or use of a provider.
19. Business information, feedback and aggregate information
Business contact information can still be personal information. Feedback, bug reports and support correspondence should not contain unnecessary member records or confidential material. We may use feedback to improve the product, but a feedback licence does not give us an unrestricted right to disclose personal information or republish a church’s confidential records.
We may use genuinely anonymised or appropriately aggregated information for reliability, planning and product analysis. Information that can reasonably be linked back to a person remains subject to applicable privacy requirements; merely removing a name or using an identifier does not necessarily make it anonymous.
We do not use identifiable church records as an advertising audience or claim an unrestricted licence to train general-purpose AI models on the contents of customer workspaces.
20. Questions and regulatory complaints
Contact PappyCoder Technologies Limited at lucasdeekay98@gmail.com to raise a concern about our processing. For a church-controlled record, identify the church so that we can involve the responsible administrator where appropriate. You may complain about BelivrHQ directly when the concern relates to our own conduct.
You may also complain to the Nigeria Data Protection Commission through its official channels at ndpc.gov.ng, or to another competent regulator where applicable. Contacting us first can help resolve a concern, but this Policy does not impose a contractual barrier to a regulatory complaint, an urgent application or another mandatory remedy.
21. Changes to this Policy
We may update this Policy to reflect changes to the service, our processing or applicable requirements. The version and date shown on this page identify the current published text. For material changes, we will provide additional notice where required or appropriate, such as an administrator email or a prominent service notice.
A revised notice does not retroactively make an incompatible use lawful or replace consent where fresh consent is required. We will identify an appropriate basis before implementing a new use that requires one. Keep a copy of the version relevant to your engagement if you need a historical record.
22. Company and privacy contact
Operator: PappyCoder Technologies Limited. Country: Nigeria. Product: BelivrHQ. Designated privacy and legal contact: lucasdeekay98@gmail.com.
This mailbox is designated by the company for BelivrHQ privacy, legal and contractual notices even though the address is not on a company-branded domain. A published contact change will not invalidate a request already properly sent to the previous address. Ask for the appropriate postal or formal service details if your matter requires physical delivery or a procedure prescribed by law.
Contact PappyCoder Technologies Limited
For BelivrHQ privacy requests, legal notices or contractual enquiries, email lucasdeekay98@gmail.com. You do not need a BelivrHQ account to use this contact.
Describe the matter and provide a safe reply channel. Do not send passwords, recovery codes, provider keys or unnecessary sensitive church records.