SEP-12¶
SEP-12 defines a standard way for stellar wallets to upload KYC (or other) information to anchors.
Configuration¶
Simply add the SEP to your POLARIS_ACTIVE_SEPS
list in settings.py:
POLARIS_ACTIVE_SEPS = ["sep-1", "sep-12", ...]
Integrations¶
Polaris is not opinionated about how anchors store customer information. Instead, it simply passes the necessary information to the integration functions outlined below for you to use.
-
polaris.integrations.CustomerIntegration.
get
(self, params: Dict[KT, VT]) → Dict[KT, VT]¶ Return a dictionary matching the response schema outlined in SEP-12 GET /customer based on the params passed. The key-value pairs in params match the arguments sent in the request with the exception of
sep10_client_account
, which will always be included in params so the anchor can ensure the customer returned was created by the same account specified in the correspondingPUT /customer
request.Raise a
ValueError
if the parameters are invalid, or raise an ObjectDoesNotExist exception if the customer specified via theid
parameter does not exist. An error response with the appropriate status will be sent using the message passed to the exception.Parameters: params – request parameters as described in SEP-12
-
polaris.integrations.CustomerIntegration.
put
(self, params: Dict[KT, VT]) → str¶ Update or create a record of the customer information passed. This information can then later be queried for when a client requests a deposit or withdraw on behalf of the customer.
If the information passed in params is invalid in some way, raise a
ValueError
for Polaris to return a 400 Bad Request response to the client. The message contained in the exception will be passed as the error message in the response. If the request specified a customer id in the request body but a record with that ID doesn’t exist, raise adjango.exceptions.ObjectDoesNotExist
exception. Polaris will return a 404 response.Return a customer ID that clients can use in future requests, such as a GET /customer request or a SEP-31 POST /transactions request. If the request included an id parameter, make sure the same id is returned.
If the required information is provided and the customer has
Transaction
objects in thepending_customer_info_update
status, all suchTransaction.status
values should be updated topending_receiver
. Polaris will then call theexecute_outgoing_transaction
integration function for each updated transaction.Parameters: params – request parameters as described in SEP-12
-
polaris.integrations.CustomerIntegration.
delete
(self, account: str, memo: Optional[str], memo_type: Optional[str])¶ Delete the record of the customer specified by account, memo, and memo_type. If such a record does not exist, raise a
ObjectDoesNotExist
exception for Polaris to return a 404 Not Found response.Parameters: - account – the stellar account associated with the customer
- memo – the optional memo used to create the customer
- memo_type – the optional type of the memo used to create to the customer
-
polaris.integrations.CustomerIntegration.
more_info_url
(self, account: str) → str¶ Return a URL the client can open in a browser to view the status of their account with the anchor. This URL will be returned in a SEP-6 Customer Information Status response. This is optional.
Parameters: account – the stellar account for the url to be returned