---
# System prepended metadata

title: Black Panther Business Rules

---

# Black Panther Business Rules
 
### Developers

1. A developer can only sign up for one developer account
2. A developer can create as many apps as need arises. 
3. There will be a 1:n app-api relationship, meaning an app can only access many apis enabled via policies
4. Billing will be done on the 30th day after successfull key request. API usage will be determined on per key usage/app_id tag usage
5. There will be no deactivation or revocation of keys unless for inactive apps. Instead, to handle billing, there will be updates of keys with different policies. For example, if a developer doesn't pay his dues, the key is updated to a different policy whose quota and rate is limited.
6. There will be no key generated for the cb2 like APIs, only apps created. If an C2B like API fails to settle its due bills the app is removed from the async API's config_data



Following our process flow,for the identification of callback urls in config data, the following url is sent to mpesa

https://api.gateway.ip/developer/pay_outs/.tyk_meta.developer_id/auth-toke?some_value

.tyk_meta.developer_id needs to change to app_id. so the config data will look like:

{
    app_id:{
    url1:value
    url2:value
    }
}

This is to avoid overwriting the config data for example when a user decides to register callback urls for another shortcode.


#### Models expounded
Messaging
    - type(invoice, payment, account, updates)
Policies
    - type(base, grace_period, limited, trial)
        - each app/key will be having atleast 2 policies set at any given time
    - We will have at least 4 policies for each api
Apps - billing_type indicates whether the billing will be post_pay or pre_pay