Supporting Multiple Downstream Applications
If your use case involves supporting multiple downstream partners / applications / developers, there are 2 ways to handle that.
- Having 1 Meld account
- Having multiple Meld accounts
In both approaches, you should pass in an externalCustomerId that corresponds to the end user making the transaction. This is just a reference id you provide, and can have any string value.
Can your downstream applications use the same set of onramps with the same fee set by you? If so, then the easiest way to support this is to use a single Meld account.
- Meld (and you) will still need to know which application is responsible for each transaction. When you call the /widget endpoint, use the
externalSubAccountCustomerIdto pass in an identifier corresponding to the application that made the call. TheexternalSubAccountCustomerIdyou pass in will be tied to the transaction the user ends up making. This is useful for compliance, metrics, and revenue calculation. - Several providers require whitelisting the domains that users will get redirected to after completing a transaction. If you will have many applications, it may not make sense to whitelist each new domain with the provider. In this case, it would make sense for you to have an intermediary redirect url with a domain that you whitelist, that then automatically redirects to the actual target url. An example would be https://yourcompanyurl.com/?redirectUrl=https://yourapplicationurl.com. Here you would only have to whitelist https://yourcompanyurl.com, but you would build an automatic redirect so that the above redirect sends the user to https://yourapplicationurl.com.
If your downstream applications need different sets of service provider and want to charge different partner fees, you may need multiple Meld accounts. Meld will need to create each account for you. Contact Meld about this. If you use 1 Meld account per downstream application, you do not need to pass in a externalSubAccountCustomerId.
The externalSubAccountCustomerId will be returned in the transaction webhooks and you can also query the /transactions endpoint with this value. This allows you to see all transactions made by a particular downstream application.
Updated 22 days ago