3 ms·

Wow, that's awesome! I've found sometimes the "verification" process of getting access to dev-docs and API keys etc. a bit of a ball-ache in the past with some

Wow, that's awesome! I've found sometimes the "verification" process of getting access to dev-docs and API keys etc. a bit of a ball-ache in the past with some providers too. What was the integration itself like in the end? Good docs/sensible API?

deergomoo 7y ago
The one small part of it I worked with (registering users) was very easy. Documentation was clear with example code in a stack of popular backend languages. Our backend is all PHP, so I just pulled in their Composer package. As I recall, all I had to do was pass it customer information and a redirect URL for where to send users after completion, and it handled the rest.
pbowyer 7y ago
My experience differs from others here. I did an integration for a national charity. A simple integration is straightforward; however if you want to test all permutations possible the support is lacking. The different documentation (their "turoial" ones, the API docs, and their helpdesk documents) contradicted at times. But the testing story was the worst part. In the end we took a "Run in production, save all GoCardless events, replay and test/correct the behaviour based on them". This was the only way we were able to get all expected properties in uncommon cases e.g. where a supporter used the Current Account Switching Service, so the DD was migrated to a new bank account. An easier way to set up the scenarios, to mock all cases, and to re-run them would be appreciated. In their sandbox, you have to wait in realtime for the next DD collection to occur. I find most payment processors not brilliant at supporting automated testing, but at least the number of card numbers etc that Stripe, Braintree et al have allow easy testing of any flows.
- jbernardo95 7y ago
  Hi Peter! I'm an engineer at GC and regarding your comment on testing/mocking we do have a tool to help with that: https://developer.gocardless.com/getting-started/developer-tools/scenario-simulators/ https://developer.gocardless.com/getting-started/developer-t... Maybe this is hidden/not clear in the documentation. I'll pass this feedback to our API team.
  - pbowyer 7y ago
    I know about the scenario simulation, and when I have corresponded with the support team it is where they have pointed me. This in spite of saying I have read it and explained why it isn't doing what we're after. In its current form, it is not adequate. We have to manually set up the resource to run it on. Once run, there is no easy reset, to re-run it (if, for example, the response was handled incorrectly). It can be argued that mocking all behaviours should be carried out our side and not involve the GoCardless sandbox. I am open to that, but note we have not seen any existing libraries handling this. And the behaviour of other payment processors suggests this is not the most common approach to take. Edit: As samples of all events/payloads are not present, we have to record production data first in order to get the data we can use in our mocking and testing.

deergomoo 7y ago

The one small part of it I worked with (registering users) was very easy. Documentation was clear with example code in a stack of popular backend languages. Our backend is all PHP, so I just pulled in their Composer package. As I recall, all I had to do was pass it customer information and a redirect URL for where to send users after completion, and it handled the rest.

pbowyer 7y ago

My experience differs from others here. I did an integration for a national charity. A simple integration is straightforward; however if you want to test all permutations possible the support is lacking. The different documentation (their "turoial" ones, the API docs, and their helpdesk documents) contradicted at times. But the testing story was the worst part. In the end we took a "Run in production, save all GoCardless events, replay and test/correct the behaviour based on them". This was the only way we were able to get all expected properties in uncommon cases e.g. where a supporter used the Current Account Switching Service, so the DD was migrated to a new bank account. An easier way to set up the scenarios, to mock all cases, and to re-run them would be appreciated. In their sandbox, you have to wait in realtime for the next DD collection to occur. I find most payment processors not brilliant at supporting automated testing, but at least the number of card numbers etc that Stripe, Braintree et al have allow easy testing of any flows.

jbernardo95 7y ago
Hi Peter! I'm an engineer at GC and regarding your comment on testing/mocking we do have a tool to help with that: https://developer.gocardless.com/getting-started/developer-tools/scenario-simulators/ https://developer.gocardless.com/getting-started/developer-t... Maybe this is hidden/not clear in the documentation. I'll pass this feedback to our API team.
- pbowyer 7y ago
  I know about the scenario simulation, and when I have corresponded with the support team it is where they have pointed me. This in spite of saying I have read it and explained why it isn't doing what we're after. In its current form, it is not adequate. We have to manually set up the resource to run it on. Once run, there is no easy reset, to re-run it (if, for example, the response was handled incorrectly). It can be argued that mocking all behaviours should be carried out our side and not involve the GoCardless sandbox. I am open to that, but note we have not seen any existing libraries handling this. And the behaviour of other payment processors suggests this is not the most common approach to take. Edit: As samples of all events/payloads are not present, we have to record production data first in order to get the data we can use in our mocking and testing.