Payment API (JSR 229)

Mobile Payment API
JSR - 229

JOSÉ ANDRÉ HENRIQUES
LUIZ TIAGO OLIVEIRA
RAFAEL ROCHA
RICARDO DAMASCENO

Mobile Payment API

Roteiro
1. Histórico e literatura relacionada
2. Estado da Arte
3. Escopo e Requisitos
4. Arquitetura
5. Comunicação
6. Pacote
7. Provisionamento de Dados
8. Segurança
9. Adapters
10. Conclusão
11. Bibliografia

Histórico

01/04/2004 Draft inicial
Releases (principais adds)
abril/2004 suporte a localização, Pay-Debug-DemoMode,
capítulo de segurança, redefinição formato SMS, etc
maio/2004 novos métodos para TransactionRecords
setembro/2004 removeu métodos gets, mudou
TransactionRecord de class para interface, registro na IANA,
publicação do Draft
novembro/2004 atualizou UML, formato SMS livre
junho/2005 Draft final proposto
30/06/2005 release final

Estado da Arte

Consolidado em países como Japão, Estados Unidos, França
Mac Donald’s – Japão
Moneo - França

Estado da Arte

MobiPay – Espanha
Joint Venture entre todas as operadoras móveis e 80% dos bancos
União de bancos e operadoras de telefonia celular
pagamento de taxi e transporte urbano
cinemas
faturas
doações
etc

Estado da Arte

PayPass – MasterCard e CitiBank (imagem)
uso em estações de metrô
Chiltern RailWays(trens): tíquetes através de celulares
Bancos

Estado da Arte

Brasil
Mobility Pass:
gerenciamento de despesas de taxi em ambiente corporativos
outros serviços
Oi Pagoo
Cartão de crédito via telefone
M-Ticket
Cliente Claro e Visa podem comprar entradas de cinema da rede
Cinemark em São Paulo (transmissão do código de barras após
pagamento) – usa PPSMS

Mobile Payment API

Literatura Relacionada
Especificação Java.Lang
Especificação JVM
JSR-30, JSR-68, JSR-118, JSR-228
Payment API Expert Group – PAPI-EG
Líder da especificação – Jean Yves Bitterlich (Siemens)
Outros representates: Sony, Symbiam, Nokya, T-Mobile,
Aplix, Mtsushita Eletric, etc

Escopo e Requisitos

Escopo
Definir uma API genérica para iniciativas de “Payment
Transaction” de maneira segura e transparente
Definir uma sintaxe de descrição de dados de pagamento para
suportar diferentes “Adapters”

Escopo e Requisitos

Escopo
Permitir que desenvolvedores construam aplicações com controle
de produtos e serviços precificados e passíveis de pagamento
Portanto, inclui métodos para:
Requisitar transações de pagamento
Requisitar gerenciamento de preços para produtos e serviços
Disponibilizar serviços de pagamento móvel

Escopo e Requisitos

Requisitos
A Payment API é um pacote opcional que roda sob:
CLDC
MIDP ou IMP
Não é uma especificação para Aplicações, mas para Payment
Module-PM e Payment Adapaters-PA.
implica que PM e PA podem adicionar outros requisitos fora do
escopo dessa especificação
• Ex: PPSMS usam JSR-120 e JSR-205

Escopo e Requisitos

Requisitos
MIDP x IMP
MIDP oferece interface com o usuário
IMP não oferece interface com o usuário
Observações
Não determina método de pagamento
API extras dependem da forma de pagamento
Premium-Price SMS (PPSMS) Japão
Vodafon e Cingular possuem SMS Center(SMSC)
Wireless API
Tipos de comunicação
SMS – Short Message Service
NFC – Near Field Communication

Arquitetura

A figura mostra os componentes do lado do terminal em uma
transação de pagamento

Arquitetura
Panorama funcional e de componentes (EN)

Arquitetura
Panorama funcional e de componentes (PT)

Arquitetura

Atores
Application: lógica do negocio, recursos da API, pode persistir
dados
prover dados no arquivo JAR-Manifest que são injetados pelo
comerciante em tempo de deploy
Payment Module: gerenciar um ou mais Adapters, interagir
com o usuário final quando necessário, interage com o Adapter,
faz a intermediação dos dados provisionados

Payment Adapter: implementa a lógica para processar um
pagamento baseado nas requisições do Payment Module,
suporta o envio do Payload (dados do pagamento), adota
protocolo de comunicação

Arquitetura

Atores
Implementer: desenvolvedor que implementa o módulo de
pagamento e ou adaptador de pagamento, em conformidade
com a JSR-229
Payment Service Provider - PSP: provê informações ao
comerciante, dependendo do tipo de pagamento também
responde pela confirmação do pagamento
Price Manager: fixa, atualiza e informa preços aos PSP
Application Provider/Merchant: Homologador e Provedor
de aplicações baseada em PAPI
Tem relacionamento com o Price Manager
Application Developer: Implementa os recursos da JSR-229
Tem relacionamento com o comerciante(merchant)

Arquitetura

Relacionamento de Confiança
Usuários finais confiam no módulo de pagamento e nos
adaptadores quanto ao sigilo das suas informações
Desenvolvedores confiam nos provedores de aplicações e nos
fabricantes quanto a não alteração das suas implementações
O Provedor de APP confia no gerenciador de preços
Os PSPs confiam nos fabricantes quanto aos terminais seguros e
compatíveis
Os fabricantes confiam nas implementações dos adaptadores

Arquitetura

Responsabilidades
Application: gerenciar seu estado interno
Payment Module:
responsabilidade = funcionalidades providas e não acessíveis diretamente
pela APP
Prover mapeamento JAR-Manifest Adapter
• dados de um APP não devem ser acessados por outra APP
Selecionar Métodos
• oferecer ao usuário uma forma de selecionar o método desejado
• em MIDP isso é simples
• em IMP não existe mais de um método
Histórico das transações
Interação de apresentação de erros

Arquitetura

Responsabilidades
Payment Module: (continuação...)
Atualização de preços e dados

Arquitetura

Responsabilidades
Payment Adapter:
Encaminhar carga de pagamentos
• adota uma carga de até 132 bytes
Prover autenticação de pagamento
Interação de apresentação de erros

Pacote

javax.microedition.payment.

Pacote

– Interface TransactionListener

• recebe notificação de registros de transações geradas pelo PM
e por conseguinte processadas
• pressupõe que o PM esteja apto a processar uma transação
– dados provisionados corretamente
• Método processed() recebe um parâmetro
– Registro que mantém o estado da transação
» SUCCESSFUL, FAILED, REJECTED
– O registro é identificado pelo ID retornado pelo método
PROCESS() que disparou o início da transação
– O registro contém:
» featureID
» Estado final
» TimeStamp

Mobile Payment API

Interface TransactionRecord
• Cada transação é representada por um objeto que
implementa esta interface

Pacote

Classe TransactionModule - TM
• Representa a ligação entre a APP e o PM
• Cada chamada do método PROCESS() retorna imediatamente
(assíncrono)

Pacote

• Construtor – instancia um objeto TM e verifica se as
informações provisionadas estão corretas
– parâmetro – o próprio MIDLet ou IMLet
• Métodos:
– SetListener() define o listener para eventos assíncronos
– Process() tem duas assinaturas
• inicia uma transação para um recurso identificado pelo
featuredID configurando no JAR/JAD
• pode gerar exceções
• se iniciado, o PM notificará a APP através do listener
quando a transação for encerrada
• o listener tem que ser definido antes de chamar esse
método

Pacote

Membros da Classe TransactionModule (continuação..)
– Process() tem duas assinaturas
• ao chamar esse método o PM deve interagir com o usuário
apresentando os dados das features bem como datas do
provisionamento
• deve pedir confirmação e seleção de método(adapter)
• Parâmetros:
– FeatureID, featureTitle, featureDescription
– payload – vetor de bytes contendo dados – ex: code activation
de um jogo (pode gerar TransactionPayloadException)
• Retorno - ID positivo e único
• Exceções
– TransactionModuleException
– TransactionListenerException
– TransactionFeatureException

Pacote

Membros da Classe TransactionModule (continuação..)

– getPastTransactions(int max)
• retorna um vetor de objetos TransactionRecord
• o tamanho do vetor é limitado pelo parâmetro max
• ordena em ordem crescente
• max = 0 nada é retornado
– deliverMissedTransactions()
• solicita ao PM para gerar todas as transações perdidas na
interface listener PROCESSED()
• não gera duplicida quando chamado mais de uma vez

Provisionamento de dados

Dados são entregues como parte do JAR-Manifest
Outros dados podem ser providos pelo JAD
O MIDLet deve proteger o provisionamento através de assinatura
do JAR
para facilitar o desenvolvimento o modo DEBUG dispensa a
assinatura


JAD

Mandatório /
Tag Opcional Descrição
Pay-Version M Versão do JAR-Manifest
Arquivo JAD e tags
Pay-Adapters M Adapters registrados. Pode ser uma
lista separada por vírgula
Pay-Debug-DemoMode O Valor boleano e se true habilita o modo
debug
Pay-Debug- (outros) O Habilita debug específico para ser
simular a falha

JAR-Manifest
Mandatório /

Pay-Update-Stamp M Data do último provisionamento
Arquivo JAR-Manifest e tags
Pay-Update-URL M URL que aponta para a última versão dos
dados de provisionamento
Pay-Cache O Especifica se vai usar cache ou não.
Valores possíveis:
[yes|no|<Expiration-Date>].
Pay-Providers M Lista de provedores suportados

Pay-feature-<n> M Representa a feature configurada para o
adapter - <n> é um número sequencial
sem lacunas e começando de ZERO

JAR-Manifest

Mandatório /

Pay-Update-Stamp M Data do último provisionamento
Arquivo JAR-Manifest e tags
Pay-Update-URL M URL que aponta para a última versão dos
dados de provisionamento
Pay-Cache O Especifica se vai usar cache ou não.
Valores possíveis:
[yes|no|<Expiration-Date>].
Pay-Providers M Lista de provedores suportados

Pay-feature-<n> M Representa a feature configurada para o
adapter - <n> é um número sequencial
sem lacunas e começando de ZERO


Arquivo JAD - exemplo

[…]
Pay-Version: 1.0
Pay-Adapters: PPSMS
Pay-Debug-DemoMode: yes
Pay-Debug-FailInitialize: no
Pay-Debug-FailIO: no
Pay-Debug-MissedTransactions: no
Pay-Debug-RandomTests: no
Pay-Debug-AutoRequestMode: accept


Arquivo JAR-Manifest - exemplo

[…]
Pay-Version: 1.0
Pay-Update-Stamp: 2004-11-15 02:00+01:00
Pay-Update-URL: http://<update-
site>/thisgame.manifest.jpp
Pay-Providers: Test
Pay-Feature-0: 0
Pay-Test-Info: PPSMS, EUR, 001, 01
Pay-Test-Tag-0: 2.40, 4321,
0x123456789abcdef0, 1

Arquivo JAD – exemplo
Uma aplicação cujo provedor suporta SMS e X-Test(adapter proprietário)
proverá os seguintes arquivos JAD e JAR respectivamente

JAD

[…]
Pay-Version: 1.0
Pay-Adapters: PPSMS, X-TEST
MIDlet-Permissions: javax.microedition.payment.process.jpp
MIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate>
MIDlet-Jar-RSA-SHA1: <base64 encoded Jar signature>

Arquivo JAR-Manifest - exemplo
[…]
Pay-Version: 1.0
Pay-Update-Stamp: 2004-11-15 02:00+01:00
Pay-Providers: SMS1, Test1Card, Test2Card
Pay-Update-URL: http://<update-site>/thisgame.manifest.jpp
Pay-Cache: no
Pay-Feature-0: 0
Pay-Feature-1: 0
Pay-Feature-2: 1
Pay-SMS1-Info: PPSMS, EUR, 928, 99
Pay-SMS1-Tag-0: 1.20, 9990000, 0x0cba98765400
Pay-SMS1-Tag-1: 2.50, 9990000, 0x0cba98765401, 2
Pay-Test1Card-Info: X-TEST8, EUR, c4d21, soap://<soap-site-1>/
Pay-Test1Card-Tag-0: 1.21
Pay-Test1Card-Tag-1: 2.46
Pay-Test2Card-Info: X-TEST8, USD, 8DiU, soap://<soap-site-2>/jsr229

Segurança

No contexto da JSR-229, segurança está relacionada com a
garantia do provisionamento de dados, da aplicação e seu
estado contra modificações não autorizadas

Trata-se também de garantir que o proprietário do terminal
tenha conhecimento de todas as transações realizadas no
mesmo

A JSR-229 foi definida e projetada para tirar vantagem dos
recursos de segurança e mecanismos de controle previstos pela
MIDP2.0.

Segurança

Requisitos
Resistência a adulteração de:
provisionamento de dados de pagamentos
do estado da informação de pagamentos
do código da aplicação de pagamentos
Proteger :
o proprietário do terminal contra sobre-pagamento
o PSP contra acesso fraudulento
o Provedor de Aplicações contra acesso fraudulento

Segurança

Permission Name
Resistência a adulteração de:
provisionamento de dados de pagamentos
do estado da informação de pagamentos
do código da aplicação de pagamentos
Proteger :
o proprietário do terminal contra sobre-pagamento
o PSP contra acesso fraudulento
o Provedor de Aplicações contra acesso fraudulento

Adapters

A JSR faz uma definição do Premium
Priced SMS Adapter e faz recomendações
de nomeação para novos Adapters

Mostra como o PPSMS devem ser
implementados

Adapters

Modelo de pagamento PPSMS
Baseado
no número Premium Priced SMS pré-definido pela
operadora
ou no valor inserido no corpo da mensagem
Essa especificação tanto é válida para SMS-MO (mobile
originated) como SMS-MT(mobile terminated)

Adapters

Especificação do Provisionamento de Dados
ADAPTER NAMESPACE - PPSMS

Tag Descrição
Pay-<ProviderTitle>-info Descreve infromações no modelo de provider
<info> - Moeda, MCC, MNC
Pay-SMS1-Info: PPSMS, EUR, 928, 99
Pay-<ProviderTitle>-tag-<m> The format is <Price>, <PremiumPriced-
SMSNumber,<Prefix>,[,NbSMS]
Prefix – um vetor de byte que antecede o SMS,uso
livre
Ex:
Pay-SMS1-Tag-1: 2.80, 9990000,
0x0cba98765401, 2

Adapters

Limitação
Formato 8-bit SMS (máx 140 caracteres)
Confiabilidade do Adapter (não é 100%)

Adapters

Exemplo arquivo JAR-Manifest PPSMS

Adapters

Exemplo
arquivo
JAR-
Manifest
PPSMS

Bibliografia

http://jcp.org/en/jsr/detail?id=229
http://wiki.forum.nokia.com/index.php/API_de_pagamento:_JSR_229
http://www.devmedia.com.br/post-10331-Artigo-WebMobile-19-
Construindo-Mobile-Payment-com-Java-ME.html
http://download.oracle.com/javame/dev-tools/wtk-cldc-2.5.2-
01/UserGuide-html/payment.html
http://innovator.samsungmobile.com/cms/cnts/knowledge.detail.view.
do?platformId=3&cntsId=7160

Payment API (JSR 229)

Mais conteúdo relacionado

Semelhante a Payment API (JSR 229)

Mais de Luiz Oliveira

Payment API (JSR 229)