Shaw Academy

Multiple systems means there is a requirement to cart data across them.

Started off with Talend scripts. This was great as what we initially had were PHP/Python script - allowed for a more systematic approach to ETL.

But ended up with a massive repository of scripts, complex crontab entries and regular failures due to memory issues.

Using Stitch or similar services is a better approach:

• no need to worry about the infrastructure needed for the ETL processes
• a more formal mapping of data from source to destination as opposed to script developer doing his/her voodoo magic
• lot of common sources and destination integrations are already builtin and out of the box @{Stitch}|tool:7199|

Multiple systems means there is a requirement to cart data across them.

Started off with Talend scripts. This was great as what we initially had were PHP/Python script - allowed for a more systematic approach to ETL.

But ended up with a massive repository of scripts, complex crontab entries and regular failures due to memory issues.

Using Stitch or similar services is a better approach:

• no need to worry about the infrastructure needed for the ETL processes
• a more formal mapping of data from source to destination as opposed to script developer doing his/her voodoo magic
• lot of common sources and destination integrations are already builtin and out of the box

Running a subscription service with just direct calls to Stripe or similar payment gateways is possible but also needs dedicated person(s) for decent amount of development and maintenance.

Plus features like updating card details, invoice history - all these can be built. Again, more dev work and resources.

Use of subscription platform like Chargebee or Recurly is definitely a great help here.

Chargebee offered a simple pay-as-you-go transparent pricing and almost trivial signup process.

#Paymentgatewayintegration

Multiple systems means there is a requirement to cart data across them.

Started off with Talend scripts. This was great as what we initially had were PHP/Python script - allowed for a more systematic approach to ETL.

But ended up with a massive repository of scripts, complex crontab entries and regular failures due to memory issues.

Using Stitch or similar services is a better approach:

• no need to worry about the infrastructure needed for the ETL processes
• a more formal mapping of data from source to destination as opposed to script developer doing his/her voodoo magic
• lot of common sources and destination integrations are already builtin and out of the box

#etl #@{etlasaservice}|topic:1323|