Payment API

[Adam Dymitruk]

Hi all,

First post here. I have a payment API that needs to do transaction processing for payment and refund. So far I have

POST: /transactions/1234?userid=blah&amount=12.50

which returns 5678 (tran ref no)

where 1234 is the /client's/ reference transaction number.

Is it ok for a refund to be

DELETE /transaction/5678

where 5678 was the tran ref no from the POST? Or is this mixing stuff up too much?

The answer I suspect is that this is mixing stuff up and is not good enough.

So as a second question, is there a standard RESTful way to go about dealing with a payment gateway?

Thanks in advance,

Adam

[Glenn Block]

In this case you, this looks like it should be PUT not POST, as you are sending the request to the resource that you want created I.e.  you are saying out this at /transactions/1234.

The main diff with POST and PUT is with POST the server decides where the resource is created, for example...

POST /transactions 

Content-Type: application/json

{

  "id" : "1234",

  ...

}

Would create the resource at /transactions/1234 and return a location header

201 Created

Location: /transactions/1234

Then the client saves the location and uses it as a bookmark for the created resource,

In this case as you are specifying the uri, it feels to me like a PUT which would return a 201 Created, but no location header necessary.

As for DELETE against the transaction for a refund, I don't see any problem with that. HTTP really doesn't care why you use it as long as the resource is removed and it is safe, meaning one delete has the same effect of multiple.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
 
 

[Adam Dymitruk]

Thanks Glenn :) didn't think I would get an answer from someone I know! What about the user of the alternate ids?

[Glenn Block]

LOL you just never know who you'll find...

 

Answer me this first which may negate my PUT comment...

 

Are you saying that POST to /transactions/1234 results in a resource created at /transaction/5678 and not /transactions/1234 ?

[Adam Dymitruk]

That's the problem. A transaction has the third party id (what they key off of) and the system has it's own too (sometimes used as confirmation code). One is used in the post and the other in the delete.

[Glenn Block]

But could I do a GET off either?

 

I.e.

 

GET /transactions/1234

 

Or

 

GET /transaction/5378

 

Also is it really /transactions and /transaction or is that a typo?

 

 

[Adam Dymitruk]

I'm following the plural form. Theoretically you could omit the id and GET all transactions in a date time range.

I guess it would be best to disambiguate the 2 and specify auth and ref in the url.. What would you suggest that look like?

[Glenn Block]

What I am asking is are there really two different resources created one with the transaction id, and one with the ref id, or just one?

[Adam Dymitruk]

Just one. With two ids. One is the internal, one is the external that the 3rd party provided

[Glenn Block]

You say two ids though, does that mean it can be accessed with either uri? Or just the one with 5378?

[Adam Dymitruk]

The record has both after a successful payment. One is the reference provided when trying to make a payment and the other is the transaction id if the payment was successful.

--

[sune jakobsson]

You might want to peak at:
http://technical.openmobilealliance.org/Technical/release_program/docs/PaymentREST/V1_0-20120214-C/OMA-TS-REST_NetAPI_Payment-V1_0-20120214-C.pdf

Sune

[Adam Dymitruk]

Link doesn't seem to work..

[Glenn Block]

I see.

Well sounds like it is still a PUT. As for having multiple URIs that point to the resource, you _can_ do that, though I wouldn't unless you really have to.

[Adam Dymitruk]

It's a payment processor. So not really restful

[Glenn Block]

I'd do this

POST /transactions 

Content-Type: application/json

{

  "id" : "1234",

  ...

}

Would create the resource at /transactions/1234 and return a location header

201 Created

Location: /transactions/5678

Then have the server save the pointer from 1234 to 5678 in a table somewhere.

The client uses the URL in the location header to then check the status or delete it.

[sune jakobsson]

Shorter and more flashier version here:
http://oneapi.gsma.com/payment-restful-netapi/

Sune