Page MenuHomePhabricator

Tech Review of LATAM processor
Closed, ResolvedPublic2 Estimated Story Points

Description

Pats is waiting to sign the contract on Tech approval. If you need more than what is offered in this, we can arrange to have a conversation with someone on their side.

API Docs: smb://filesrv1.corp.wikimedia.org/Fundraising/Tech/Astropay/API APD version 4.1.pdf

There are more docs available for the business side and the customer flow in that folder as well.

Tech notes

Looks like a typical hosted flow. The initial payment call returns a redirect URL and we present in the Location header.

No chargebacks, cos prepaid and guaranteed.

All communication can be done over POST, with no SOAP. We can specify either json or xml response formatting.

Final redirect from AP to our merchant URL includes a result code, which is good enough for Thank You / failure routing, but not for final confirmation.

We set the x_confirmation URL and they real-time notify us of payment. Once this notification is received, we’re supposed to make a webpaystatus request back to them. FIXME: this extra request is only needed because the real-time notification message lacks the currency field.

We need to collect the donor’s account number in our form, but not necessarily their bank ID—see below.

We should provide the vendor with the donor’s country code, because in that case we don’t have to collect their bank ID, it is done by an existing AP screen. However, we do not actually know their billing address country, only a guess based on country of web request. This will result in “Problems Donating”, which we’ve decided to accept as long as it’s at a low level.

The vendor responds with x_document, their unique transaction ID, in the final redirect from their workflow. If we miss the message, we’ll have to wait for the real-time confirmation.

We should parse the error code into something customer-readable, see section 5.1.

All requests from us and responses from them are signed, and over https.

This gets weird: We’re probably going to have to absorb 0.38% of IOF tax, but since that’s added on top of our charge, we should divide by 1.0038 to calculate the x_amount of our request.

Supported countries:

  • Argentina
  • Bolivia
  • Brazil
  • Chile
  • Colombia
  • Costa Rica
  • Mexico
  • Paraguay
  • Peru
  • Uruguay
  • Venezuela

Thing to check

Is there a setting to roll taxes into the donation amount (we eat), or do we have to reduce the amount by the reciprocal of tax before starting the transaction?

Configuration

  • Get our secret keys for signing API requests.
  • Verify HTTPS certs when making API calls. They should give us a static list of IP addresses to unfirewall. We give them our IPs.
  • How do we test? My guess is that we just pay using a test account. Ask for these, for a few bank and country combinations.

Future

They support gateway recurring. See “AstroPay API - Credit Cards - Preapproval - v2.5.pdf”. It looks like we’ll need to handle CC numbers, however, so we probably can’t take advantage of recurring.

Event Timeline

@awight this is done, right? can we mark as closed?

Now that I think about it.. maybe it's just mostly done.

The last missing part is the subtask to figure out how to do audit delivery.

I don't think we can close this as it's blocked on the audit delivery. Moving back to Pending Deployment.

atgo edited a custom field.
atgo claimed this task.
atgo renamed this task from Tech Review of AstroPay to Tech Review of LATAM processor.Feb 2 2015, 10:35 PM
atgo removed a subscriber: awight.
atgo added a subscriber: awight.

OKAY, now we're reviewing the "Streamline API v1.7" document.

This integration will get us credit card, online bank payment, Boleto (BR) and OXXO (MX).

In Brazil, the following banks and cards are supported,
I Itau
BL Boleto
B Bradesco
BB Banco do Brasil
H HSBC
SB Santander
CA Caixa
VI Visa
MC MasterCard
EL Elo
DC Diners Club
HI Hipercard
ML Cartao MercadoLivre
AE American Express
VD Visa Debit
MD MasterCard Debit

Cardholder information is entered on the customer's own bank page, as we expected.

I have the following questions out to the processor:

  1. In the document, you say "[the processor] needs the merchant to collect some key data (email address and personal identity number – eg CPF number in Brazil)." however, the API says we will also need to collect the customer's birth date. Please let us know whether that value is mandatory or not.
  1. The customer is redirected to their own bank to enter the remaining financial information, but what does that mean for credit card payments? Are they actually redirected to another credit card processing entity? Can you provide us with that entity's identity and point us to their SSL certificates?
awight changed the task status from Open to Stalled.Feb 12 2015, 11:05 PM

(I'm just using the "stalled" status to indicate that we're waiting for answers here.)

awight moved this task from In Development to Done on the § Fundraising Sprint Devo board.