Summit Development and Integration Best Practices
Primary goals of the Summit platform include simplicity and rapid development. On the other hand, Summit implements a robust set of functionality and therefore it can be misused to create an unfavorable user experience as well as certain security risks.
This documentation outlines the most prevalent concerns about industry compliance as well as other best practices that should be followed to give your users a positive and safe experience.
Performance & Reliability
When designing integration between Summit and your other systems, it is important to consider certain priorities and trade-offs around the behavior of those interactions.
By default the HTTP client will automatically retry when it encounters a timeout. For sensitive operations such as financial transactions, your service and Summit application should support an “at-least-once” delivery policy. The HTTP client will include a header X-Request-ID that you can use to deduplicate requests, or you can use your own identifying values in your application.
In the unfortunate event that your service becomes unreachable, your Summit application should implement some user-friendly behavior that either provides an alternate routine, or informative and comforting information about the problem.
When designing Summit applications, keep these topics in mind to help keep your users happy.
- Avoid making users enter the same information more than once.
- Avoid making users wait in silence for long operations.
Security, Privacy & Industry Compliance
Summit is compliant with industry standards, but only when used correctly and safely. Certain practices need to be incorporated into your development process in order to ensure compliance.
By following the recommendations in this document, you can build your system to be PCI & HIPAA compliant.
Always restrict logging before collecting or transmitting any personally identifiable information.
In an app that handles sensitive information, it is recommended that you always set logging to restricted_mode or silent_mode, and only switch to verbose_mode deliberately when testing.
Be aware that plenty of library calls including arguments will be implicitly logged when logging is set to verbose_mode.
In conclusion, if you handle sensitive data, you should restrict or silence the logging system for your application.
Read more about the log library.
In general, avoid sending sensitive information (including system credentials) in HTTP GET queries, as that information tends to appear in HTTP server access logs.
Avoid implementing HTTP services that are not well guarded by strong authentication and authorization, unless you are okay with unidentified parties accessing their functionality.
Read more about the summit HTTP client library.
HTTP Client Whitelisting
You may additionally guard your HTTP server by whitelisting the Summit HTTP client IP addresses.
All HTTP Requests from Summit will exit from the following addresses:
- 184.108.40.206 (out-1.mci01.proxy.corvisa.io)
- 220.127.116.11 (out-2.mci01.proxy.corvisa.io)
- 18.104.22.168 (out-3.mci01.proxy.corvisa.io)
- 22.214.171.124 (out-1.ord01.proxy.corvisa.io)
- 126.96.36.199 (out-2.ord01.proxy.corvisa.io)
- 188.8.131.52 (out-3.ord01.proxy.corvisa.io)
As the sensitivity of your information systems increase, so must your diligence regarding protecting them and systems that interact with them, such as Summit.
Use your best discretion when storing credentials for accessing remote systems.
If you are publishing a Summit application with permits to other organizations, you likely will not store credentials in the Summit application itself, unless it is a specific integration to your system. In that case make absolutely certain that you are not leaking information in logs to your customer’s summit account.
If you are building a reusable Summit application that may interact with many different services or many different accounts, it might make more sense to store those configurations in the Application Datastore.
Use discretion when recording voice calls. Summit provides utilities for automatically encrypting call recordings, as well as methods to toggle live calls recording state on the fly. Check this documentation in the future for more information, or contact an on-boarding specialist for help.
Summit REST API Keys
If you must create REST API Keys for Summit, then you must also consider some precautionary measures to protect them. Protect your API Keys with care so that they are not inadvertently shared, which can seriously compromise the security if your Summit account in terms of privacy, data integrity, and financial cost.