IxDF Developer Docs

Appearance

Is it safe to do operation X on server Y? ​

This document will help you execute operations that contain 3rd party services on a specific server with more confidence. Although it’s basically intended for developers, it can help anyone who’s using IxDF’s administrative interface. Let’s begin.

  1. Payment Gateways
  2. Cloud Services (AWS)
  3. Mail Services

1. Payment Gateways ​

We currently have 2 different payment gateways: Stripe and PayPal. Both of them have their own production and test environments. As you may guess, both Stripe’s and PayPal’s production environments are used only on our production server (https://www.interaction-design.org). The other servers (look at the full list here) are using test environments.

Based on the information above, you’re safe to make payment-related operations on non-production servers. You can pay for a new membership using either Stripe’s credit cards or PayPal’s test account (both shown here), change membership plans, issue refunds etc.

On Renewals ​

PayPal does not let us do renewals. However, we have that option on Stripe. When we charge a credit card through Stripe successfully, Stripe saves that credit card into their systems and gives us a payment token. We are able to charge a specific card again with its payment token. Thus, even though we don’t store credit card information, we can get additional payments.

However, Stripe is using different databases for its live (production) and test environments. It means that you won’t be able to test a renewal on a non-production environment by using a payment token given by Stripe’s production environment. Long story short: The payment tokens in our payment table (in MySQL database) are not valid on our non-production environments.

2. Cloud Services (AWS) ​

We don’t currently have a test environment for our cloud services (AWS). We actually have our non-production links (e.g., https://public-media.information-architecture.org) as well as our production links (e.g., https://public-media.interaction-design.org). Yet, if you want to upload an image to the cloud (e.g., uploading a profile picture) on a non-production server, it will actually be uploaded. Same thing is valid for removing an image too.

Still, both of our end-user and administrative interfaces do not have an option to remove something from the cloud. That’s why it’s practically safe to play around with AWS on non-production servers. However, developers, be careful when playing around AWS.

3. Mail Services ​

We currently use mail service: Mailgun.

What is a transactional email? ​

Transactional emails contain all emails sent from our system automatically.

Someone becomes a member, and we email them saying welcome? It’s a transactional email. A member forgets her password and we send them instructions to create a new one? It’s a transactional email. A member completes their course, and we email them congratulating their along with their course certificate? It’s a transactional email.

A member requests support by using the contact form, and we reply to their request from the member support box? It’s NOT a transactional email. It’s sent manually by us, from a real inbox AND not programmatically and automatically.

Mailgun ​

We don’t use Mailgun’s test environment, simply because they keep charging us per email sent basis even in the test environment. The second reason is that it’s rather hard to reach out to the output. On non-production environments, we are using Laravel’s log files to save the output of an email when it’s sent. Hence, it’s pretty safe to play around with transactional emails.