summaryrefslogtreecommitdiff
path: root/template
diff options
context:
space:
mode:
authorStefan Kügel <skuegel@web.de>2023-12-18 22:27:08 +0100
committerStefan Kügel <skuegel@web.de>2023-12-18 22:27:08 +0100
commit4bdc5f5809a2c4fe9072ba7b348907e933c77ece (patch)
tree2e504ff265927bd5fe94af7360f863f63550e536 /template
parent999c42916c2d842cf1371037c89065025b727c2b (diff)
downloadwww-4bdc5f5809a2c4fe9072ba7b348907e933c77ece.tar.gz
www-4bdc5f5809a2c4fe9072ba7b348907e933c77ece.tar.bz2
www-4bdc5f5809a2c4fe9072ba7b348907e933c77ece.zip
rectify typos
Diffstat (limited to 'template')
-rw-r--r--template/kyc.html.j220
1 files changed, 10 insertions, 10 deletions
diff --git a/template/kyc.html.j2 b/template/kyc.html.j2
index 4ddfe1dc..0ed6ebbc 100644
--- a/template/kyc.html.j2
+++ b/template/kyc.html.j2
@@ -6,11 +6,11 @@
<p>
GNU Taler operators need to satisfy regulatory requirements in terms
of Know-your-customer (KYC) regulation and risk assessment (which
- usually starts with checking for politically exposed people (PEPs)).
+ usually starts with checking for politically exposed persons (PEPs)).
KYC usually requires at the minimum for the customer to upload some
identity documents, which then must be verified. KYC often also
- requires some kind of lifeness checks to ensure tha the owner of the
- documents it the one passing the documentation along.
+ requires some kind of lifeness checks to ensure that the owner of the
+ documents is the one passing the documentation along.
To this end, we have tried to find KYC "solutions" that would
help us address this.
</p>
@@ -27,7 +27,7 @@
integration on the client-side, having an open API specification
(no NDA!), or even supporting a standard API. Technically, we
also need the KYC provider to work nicely over the
- Web (not just with a smart phone), and from a business perspective
+ Web (not just with a smartphone), and from a business perspective
we like transparent pricing (alas, this is the least important
point).
</p>
@@ -37,17 +37,17 @@
<ul>
<li>Supports collecting and validating KYC information, including PEP lists and ID documents from Europe
</li>
- <li>Open API specification (no NDA, directly on Web site)
+ <li>Open API specification (no NDA, directly on web site)
</li>
- <li>Web interface support (no required App-only integration, can run KYC process just in a browser)
+ <li>Web interface support (no required app-only integration, can run KYC process just in a browser)
</li>
<li>Supports standard open API (OpenID, OIDC, etc.)
</li>
- <li>Client-side code is FLOSS (no proprietary JavaScript and/or FLOSS App integrations)
+ <li>Client-side code is FLOSS (no proprietary JavaScript and/or FLOSS app integrations)
</li>
<li>Transparent pricing (prices not only upon inquiry)
</li>
- <li>Server-side is fully FLOSS (not SAASS)
+ <li>Server-side is fully FLOSS (not SaaSS)
</li>
</ul>
The list is not intended to be complete. Other criteria would include where
@@ -86,14 +86,14 @@
(see below for lists of other providers we considered),
and we needed <em>some</em> KYC support.
That said, there is room for improvement for both of these
- solutions towards respecting their user's freedom.
+ solutions towards respecting their users' freedom.
</p>
<p>
Adding support for additional KYC providers largely requires
implementing a KYC plugin, that is a shared library exporting
the <a href="https://git.taler.net/exchange.git/tree/src/include/taler_kyclogic_plugin.h">
KYC plugin API</a>. If you need help implementing additional
- KYC adapters, please do not hestiate to contact
+ KYC adapters, please do not hesitate to contact
<a href="https://taler-systems.com/en/company.html#contact">us</a>, we will
be happy to support your efforts!
</p>